Ask what a migration between two systems costs, and the honest answer is usually: about the same as the last one. That is the problem worth solving, and it is an architectural problem before it is a commercial one.
Why pairs are expensive
Connect two systems by writing code specific to those two systems, and the cost of your catalogue is the cost of a pair multiplied by the number of pairs you support. Add a system to a catalogue of ten and you have not added one unit of work - you have added the work of connecting it to ten things.
That shape has consequences that show up everywhere in this market. Catalogues grow slowly, because each entry is real engineering. They stay inside one domain, because crossing into a different kind of system means the accumulated pair-specific code doesn't transfer. Reverse directions are rare, because the second direction is a second body of software that earns a fraction of the first. And the hard parts - the references, the structure, the fields that don't have an obvious home - get cut, because they cost the most and their absence isn't visible on the day of delivery.
None of this is anyone being lazy. It is what the multiplication does. If every pair is its own codebase, then every pair has its own budget, and no budget is ever large enough to do the last 20% properly.
What has to change
The cost of the nth pair only drops if the pair stops being the unit of engineering.
So: one engine, which knows about generic things - collections, records, schema definitions, content, relationships between records - and knows nothing about any particular product. Each system gets a description instead of an integration: how it authenticates, how it paginates, what entities it exposes, how records are constructed in it, how references inside its content behave.
A pair is then two descriptions and a mapping between them. Not a codebase. A document.
The arithmetic changes shape. Adding a system is one description, not one description times the size of the catalogue. And every pair that already exists can reach the new system as soon as its description does, because nothing in between was written for a specific pairing.
Where the effort goes instead
The work does not disappear - it moves. It concentrates in the engine, where it is spent once and benefits every pair simultaneously.
That is what makes the hard 20% affordable for the first time. Resolving references that form cycles, or point forward, or cross out of the migration entirely, is genuinely difficult and takes real engineering. Under the per-pair model it has to be justified against one engagement's budget, so it gets cut. Built into a general engine, it is justified against every migration the system will ever run - and every pair added afterwards inherits it without asking.
The same is true of resumability, of idempotent writes, of the append-only history, of sampling both sides and comparing them field by field after a run. None of these are features anybody would fund for a single pair. All of them are obvious once they are funded once.
What this does not mean
It would be dishonest to claim a new pair costs nothing.
A description has to be written, and writing it means understanding a system properly - its authentication, its pagination, its entity model, the specific ways its content references itself. An agent can draft that description by reading the live API, and it does, which turns a project into a review. But someone still reviews it, and reviewing it well requires knowing what to look for.
A pair also has to be proven. A description that looks right and a description that survives contact with a real instance are different things, and only running one against live data tells you which you have. That is per-pair work and it does not amortise.
What amortises is everything underneath: the ordering, the reference resolution, the failure isolation, the resumption, the verification. So the honest claim is narrower than free, and more useful. The nth pair costs a description and a proving run - not a project. The difference between those two is the difference between a catalogue that grows in weeks and one that grows in years.