Building your own algorithm is never a good idea. Even trained cryptographers, i.e. the people who toiled for years in the dark tunnels of academia and the battlefields of scientific congress, will resort to such inventiveness only when everything else has failed; and even then, they prefer to suggest schemes to be validated by their ferocious peers, certainly not to be deployed in production right away. Most of academic training is about acquiring an intuitive knowledge of the dangers of one's field.
Designing your algorithm is like tap-dancing in a minefield.
Nevertheless, the impossibility to simply extend the number of iterations of a stored hash, beginning with the hash value itself, is a known defect of the usual candidates (PBKDF2, bcrypt and scrypt). If you have to live with it, you could try the scheme described there, but I explicitly deny that security would be increased that way. My training and years of experience in the field allow me to state with some confidence that the extra hashing rounds I suggest would not decrease security.
In the future, things will be better because a new open competition for password hashing algorithms has been launched, using the model of the previous AES, eSTREAM and SHA-3 competitions. Submissions are due for the end of January 2014. A portfolio of "good algorithms" will be obtained by mid-2015, according to the provisional timeline. The call for submissions explicitly includes the following desired functionality:
Ability to transform an existing hash to a different cost setting without knowledge of the password.
So we can hope for a solution to your problem in a bit more than two years. Only two years, that's really fast by cryptographic design standards.
In the mean time, you will have to resort to the usual arrangement of waiting for the users to log in so that their password can be rehashed with more iterations. Most users who have not logged in for more than one year have probably forgotten their password anyway.