Most migrations fail on the things nobody wrote down.
The application inventory is never the hard part. The hard part is the scheduled task on a server under someone's desk, the firewall rule with no ticket, and the licence that does not transfer. We find those first.
- platforms
- AWS · Azure · GCP
- starts with
- Dependency mapping
- we hand over
- Terraform you own
A migration plan is only as good as its dependency map.
Every organisation we assess has at least one system that everything quietly depends on and nobody owns. It is usually a file share, a scheduled job, or a database link written in 2014. It does not appear on the architecture diagram because the person who built it left.
We spend the first two weeks finding those, because they are what turns a six-week migration into a six-month one. The output is a dependency map that is accurate on the day we hand it over — including the parts that are inconvenient.
What the practice covers
Migration is the headline, but much of this work is for teams already in the cloud and paying more than they should for it.
Migration planning and execution
Dependency mapping, wave sequencing, and cutover runbooks rehearsed against a restored copy before they touch production. Every wave has a rollback that has actually been tested, not just documented.
Cost optimization
A line-by-line review of what you are billed for versus what you use. Commitment coverage, storage tiering, idle non-production environments, and the three instances nobody has logged into since a project ended. Findings come with the annual figure attached.
Hybrid and multi-cloud
Connectivity, identity federation, and a clear answer to which workloads should stay where. We will tell you when multi-cloud is costing you more than it saves — which is often.
Infrastructure as code
Terraform or Bicep, in your repository, with a state backend you control and a plan step in CI. Click-ops becomes the exception rather than the record of truth.
Resilience and disaster recovery
Recovery objectives agreed with the business, then tested against them. A restore that has never been performed is a hypothesis, and we treat it as one until it runs.
Landing zones and account structure
Account separation, guardrails, tagging that survives contact with real teams, and network topology laid out before the first workload lands rather than reorganised around it afterwards.
How a cloud engagement runs
Nothing moves until the dependency map is signed off. That single rule prevents most migration overruns.
Discover and map
Read-only access, network flow capture, and interviews with the people who get paged. We produce an inventory with owners and dependencies, including everything running that shouldn't be.
Sequence by risk and cost
Workloads are grouped into waves. Each wave carries an estimate, a rollback plan, and a note on what breaks if you defer it. You can approve wave one and hold the rest.
Land the platform, then migrate
Landing zone, identity, and network first — as code. Then waves, each rehearsed against restored data before the production cutover, and each ending with something running.
Operate and tune
Cost review on a monthly cadence, right-sizing against real utilization, and a quarterly restore test. This is where the savings actually land.
A datacentre exit that finished on the lease date
Drawn from engagements the founders ran at previous employers, before CloudMind existed. It is not a CloudMind client reference, and we will not present it as one.
A colocation lease expiring in nine months, 140 virtual machines, and an architecture diagram three years out of date. Two prior attempts had stalled at the discovery stage.
What we did
- Six weeks of flow capture and interviews, producing a dependency map that found 19 undocumented integrations
- Nine migration waves sequenced so the warehouse management system moved last, after everything it depended on
- Each cutover rehearsed twice against restored snapshots before the production window
- Landing zone, network, and IAM delivered as Terraform in the client's own repository
The discovery phase felt slow until it surfaced the two integrations that would have taken down order intake on cutover weekend.
- Lease exit, on date
- 9 moLease exit, on date
- Undocumented integrations found
- 19Undocumented integrations found
- Run-rate below colo cost
- 34%Run-rate below colo cost
[PLACEHOLDER STAT] Figures are illustrative. Replace with real numbers from the founder’s prior engagement, cleared by that employer and with a contactable reference — or remove the section until one exists.
What people ask before they sign.
If your question is not here, ask it directly — we would rather answer it now than in month three.
Which cloud should we be on?
Usually the one your team already knows. The difference in capability between AWS, Azure, and GCP matters far less than the difference between engineers who have operated a platform at 3am and engineers who have not. Existing licensing agreements and identity estate are the next strongest factors — if you are heavily invested in Microsoft identity, Azure removes real friction.
Will this actually reduce our costs?
A lift-and-shift on its own usually does not, and anyone promising otherwise is not counting the same things you are. Savings come from right-sizing, commitment coverage, storage tiering, and shutting down what nobody uses — which is optimization work, and it can start before any migration. We often run it first because it funds the rest.
Can you work alongside our existing team rather than replacing them?
That is the normal arrangement. Your engineers know the systems; we bring migration patterns and the time to do discovery properly. We pair deliberately during cutover work so the knowledge stays with you afterwards.
What happens to the infrastructure code if we stop working with you?
It is in your repository, under your account, from the first commit. There is no CloudMind-hosted state backend, no proprietary wrapper, and no module registry you need a licence for. Leaving should be a decision, not an extraction.
How much downtime should we plan for?
It depends on the workload, and the honest answer is that some cutovers need a window and some do not. Databases with replication can often move with minutes of downtime. A monolith with a local filesystem dependency may need a weekend. We tell you which category each workload falls into during discovery, before you commit to a date.
Start with a cloud & infrastructure assessment.
Two weeks, fixed fee, no commitment to a build. You end up with a written account of what you run today and a costed plan — yours to keep even if you take it elsewhere.