Well, you could do something like:
- Create your "router" database
- For all the objects accessed in B, create synonyms/views in the router DB pointing to those in B over the DB link, e.g.
create or replace view vw_b as select * from vb_b@dblink_to_b;
- Update the DB link in A to point to B
- Gradually change the views/synonyms in the router DB to point to C, such as:
create or replace view vw_b as select * from vb_b@dblink_to_c;
- Switch out the router DB when you're done
Of course, this introduces an extra layer of network hops between A and the final database. Which may slow things down. Particularly if you'll have queries accessing tables from B and C at the same time.
You could mitigate this using materialized views to stage data into the router DB. Of course, this makes switching objects from B -> C more complicated.
So another option to consider:
Does C actually need to be a separate database? Or can it be a schema within B?
You can stick with the view/synonym approach I described above. But instead of changing the DB link, you're just updating the schema.
This avoids the extra network roundtrip and keeps all the data in one database. Which can help if you want to join tables in the old and new systems.
But of course, that brings the bigger question of why you're trying move B -> C at all ;)