A quick note on migrations
A sort of epilogue to the doing.
Following on from the last post of the doing, it occurred to me I should quickly talk about the migration work undertaken as I glossed over it.
As a caveat, it’s again worth pointing out that the migrations are ongoing, so this might all change as I start getting into the guts of the work.
From an infrastructure POV, it’s ready to go. So what did I need to consider when migrating from the existing to the new?
From a high-level, it was pretty simple. The plan was environment by environment, starting with everything in DEV, then Unqualified (Test), Qualified, and then Prod. So five new Technical stacks (if I include the DR as well) and then 18 Environment stacks split across those.
We ran the existing alongside Greenfield, deploying the application into Kubernetes. When we were ready, we arranged downtime and completed the following migration tasks:
Set up new user accounts and allocated access permissions for clients into SFTP;
Migrated any data from existing virtual machines to new;
Migrated and restored data from the Postgres instances;
Migrated and restored data from the MongoDB cluster instances;
Changed the DNS records so services switch from existing to new.
And that was it. As I have mentioned, this might be subject to change as the migrations start to take more shape.