DBConvert

Database migrations rarely fail at the copy. They fail around it: types the target engine does not have, views and stored code nobody has read since 2009, a cutover window measured in hours against a source that never stops taking writes, and a rehearsal that has to be repeated a dozen times without costing more each round.

That is the work we take on. We have been building database migration and replication software since 2001 under the DBConvert name, and when we run a migration for a client we run it on our own engine. When the conversion gets something wrong, we change the code. There is no vendor in the middle and nothing to wait for.

Engagements come in three shapes. A one-off conversion and cutover, scoped and quoted as a fixed project. A repeatable synchronisation or change-data-capture pipeline, built, tested and handed over with a runbook so your team owns it afterwards. And the work most firms decline: data locked in FoxPro, dBase or Access, usually inside a system whose author left years ago.

We work with SQL Server, Oracle, MySQL, PostgreSQL, MariaDB, IBM DB2, Firebird, SQLite and the desktop formats above, on premises and into managed cloud databases on AWS, Azure, Google Cloud, Neon and Supabase.

How we charge does not change between clients. Diagnosis is free, however long it takes and whoever turns out to have caused the problem. Building, running or taking responsibility for something is quoted in writing before it starts and never invoiced afterwards.