1,100 database projects, six engines, one set of practices.
At this scale the difficulty stops being any individual database and becomes the absence of a shared way of doing things.
1,100 database projects 6 engines BPO engagement model
The situation
A public research institution accumulates databases the way a university accumulates buildings: one project at a time, each with its own reasons, over decades. The result was around 1,100 database projects spread across SQL Server, PostgreSQL, Oracle, MySQL, MariaDB and MongoDB.
Individually, most were fine. Collectively there was no answer to the questions that matter operationally — which of these are backed up, which are still in use, who owns this one, and what happens if this server goes away.
Practice before tooling
The work was not primarily technical. It was establishing organisational practice: how a database gets created, who is responsible for it, how it is backed up, how it is monitored, and how it is retired when the project that needed it ends.
Six different engines means six different ways to do each of those things. The practice has to be uniform at the level of intent and specific at the level of execution — a backup policy that says the same thing for Oracle and MongoDB is a policy nobody can follow.
Why it holds
An estate this size cannot be held together by attention. Anything that depends on someone remembering will fail the moment that person is on leave, and at 1,100 projects somebody is always on leave.
What survives is what is written down and repeatable — which is also, not coincidentally, what can eventually be automated.
Tell us what you are trying to fix.
A tangled integration, a slow database, a system nobody understands any more. The first conversation is 30 minutes and costs nothing.