Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.
Context
An organisation running its core operational systems on infrastructure owned and operated by its software vendor.
The arrangement was convenient until it wasn't: the client could not decide where its data lived, when its systems were updated, or how they were configured.
The problem
- Hosting, and therefore the data, sat with the vendor.
- Release timing and configuration were outside the client's control.
- Moving away was hard by construction, which is what vendor lock-in means in practice.
- There was no infrastructure definition the client owned, so the environment could not be reproduced elsewhere.
- Deployment depended on the vendor's process rather than the client's.
What we built
Migration of the production instances
To the client's own on-premises and cloud environments, running in parallel until each was proven.
Infrastructure as code
So the environment is a definition in the client's own repository rather than a configuration that exists only on a running server.
Automated deployment pipelines
So releases are the client's decision and a routine operation.
A container-based deployment
Moving from virtual-machine hosting to orchestrated containers, which is what made the environments portable.
How we delivered it
- 1
Inventory the existing environment
What is running, how it is configured, and what depends on it. Much of this had never been written down.
- 2
Build the target environments as code
On-premises and in cloud, before moving anything.
- 3
Migrate in parallel
With the vendor-hosted system live until the new one was proven.
- 4
Cut over
With a tested path back.
- 5
Hand over operations
Runbooks, monitoring, backup and recovery, all owned by the client.
How it was phased
Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.
What the client keeps
- Infrastructure definitions in their own repository
- Deployment pipelines
- Runbooks for every recurring operation
- Monitoring and backup configuration
- A tested recovery procedure