Well, I'd suggest BCrypt over PBKDF2.
That being said, your solution should be two-fold.
To secure the system immediately, yes your solution is good. Treat the MD5 as the input password, and have per-user salt as you suggest.
I would suggest migrating MD5 out of the picture. (unless this is strictly legacy application)
Next time the user signs in, your application will have access to the unhashed password, and will have the ability to update the hash with one that skips the MD5 step. You'll have to have some indicator on the account as to whether this has been completed.
I would also recommend pre-pending Pepper to the input password (or MD5) as an additional security precaution.
BCrypt has a max length on passwords, so it is best to place the input password combined with Pepper in an SHA-256 hash first. I'm not sure if PBKDF2 has this limit. Eventually you may one day use an even newer hash that does not have this limit either.
You know, really, migrating off of MD5 is probably not necessary, but getting rid of MD5 would be the ideal solution for best collision resistance and just seems like a cleaner design.