Production database moved on-prem to cloud in 24 hours

Context

The digital archive of a UK archaeology company: a Laravel application on PostgreSQL with spatial extensions, holding field data collected over decades. It ran on an ageing on-prem hypervisor, in a building the client was about to leave.

Problem

The database had been shutting itself down in production at irregular intervals for months. The previous team restarted the service and moved on. Nobody had found the cause, and the move to the cloud kept being postponed precisely because of that instability.

What I did

1. 01Incremental sync of the data over several days, with the old system left running
2. 02Resolved a glibc collation mismatch between the two operating system versions, which would have silently corrupted index ordering
3. 03Removed conflicting PostgreSQL versions left on the machine and rebuilt the spatial extensions missing from the official repositories
4. 04Found the real cause of the shutdowns: a messaging extension incompatible with the broker major version installed in the meantime. Rebuilt from source against the correct version
5. 05Final delta of 722,425 files, verified end to end by checksum
6. 06Repointed the build pipelines, message queues and monitoring at the new location