The database that stayed

The services moved. The UI moved. The batch jobs got found and moved. And in the middle of the modernized estate, the same database that was there in 2009 is still there, forty applications deep, schema like tree rings. This is not a failure story. Half the time, it is the correct ending.

Why the database moves last: applications hold behavior, but the database holds agreements. Every one of those forty applications agreed, over the years, on what a customer is, when an order is final, which column means what despite its name. Moving code relocates logic. Splitting a shared database renegotiates every agreement at once, and the negotiating parties include batch jobs, reports, auditors and two systems owned by companies you acquired.

The checklist for whether to even try:

1. Count the writers, not the readers. Readers can be weaned onto views, replicas and APIs at leisure. Every additional writer to a table multiplies the coordination cost of any split. Ten writers on one schema is not a database; it is a treaty organization.
2. Find the transactions that span domains. The order-insert that updates inventory and ledger in one commit is the agreement that a split converts into a distributed systems project. List these first; they price the whole endeavor.
3. Check the accounting calendar. Month-end consolidates sins. A schema that looks separable on a Tuesday is welded shut at quarter close.

When the split is genuinely warranted (divergent scaling, regulatory isolation, a domain with a real boundary), the order is fixed: new owner service in front of the tables first, every other consumer rerouted through it at strangler pace, the physical split last, once the logical one has held for a full cycle. Shops that reverse this (physical split first, cleanup after) buy themselves a parallel-run that never converges.

And when it is not warranted, say so in writing. A shared database, tuned, on current hardware, with views as the compatibility layer and an owner who reviews schema changes, is a fine center for an estate. Modern single-node capacity is enormous; the ceiling most shops fear is decades of unexamined queries, which is a tuning project, not a distributed one. The database that stayed is only a problem if it stayed by default. Stayed on purpose, with the reasoning dated and filed, it is the cheapest decision on the roadmap.

Respect the old thing. It has kept the agreements longer than anyone still at the company. The job is to make the agreements explicit, not to scatter them across a service mesh and call the confusion progress.