The risky part of a migration is rarely copying the data. It's the hard-coded IP address, the batch job nobody listed and the service account whose password sits in a config file. We find those before the wave plan is final.
Cloud migration moves applications, databases and infrastructure from a data center or another cloud into AWS, Azure or Google Cloud.
Cohash maps dependencies, plans migration waves, rehearses each cutover with a rollback path, and moves workloads with tools such as AWS Application Migration Service and Azure Migrate. As each application moves, we replace embedded passwords and keys with managed identities and IAM roles.
you probably need this if
Nobody is sure which servers talk to which, so every move feels like it might break something.
The data center contract ends on a fixed date, and the migration plan is still somebody's spreadsheet.
Applications have database passwords hard-coded in config files that would move to the cloud unchanged.
terms on this pageService accountdefinitionA non-human account that software signs in with. Shared ones tend to pick up years of extra permissions.explained in a field note →WavedefinitionOne batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.explained in a field note →CutoverdefinitionThe moment traffic and users switch from the old system to the migrated one.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Cloud Migration, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · cloud migration3 open
openNobody is sure which servers talk to which, so every move feels like it might break something.
recurringThe data center contract ends on a fixed date, and the migration plan is still somebody's spreadsheet.
blockedApplications have database passwords hard-coded in config files that would move to the cloud unchanged.
exposure
Discovery and dependency mappingWave planningRehost and replatformCredential cleanup in flightCutover and rollback
startrehearsehandover
Discover
Plan waves
Pilot
Migrate in waves
Optimize and hand over
we are here
ready to hand over
Now the wave plan says which workloads can move before the renewal and which need a…
The shared database stops being the hidden reason waves slip.
The team goes into the next cutover with a rollback it has already run and timed, and…
Dependency map and application inventory
chapter 01 · where it hurts
Why teams reach out
Nobody is sure which servers talk to which, so every move feels like it might break something.
The data center contract ends on a fixed date, and the migration plan is still somebody's spreadsheet.
Applications have database passwords hard-coded in config files that would move to the cloud unchanged.
chapter 02 · what we change
How we solve it
Discovery and dependency mapping
Wave planning
Rehost and replatform
Credential cleanup in flight
Cutover and rollback
chapter 03 · how it runs
Our approach
Discover
Plan waves
Pilot
Migrate in waves
Optimize and hand over
chapter 04 · where you end up
What changes
Now the wave plan says which workloads can move before the renewal and which need a short extension.
The shared database stops being the hidden reason waves slip.
The team goes into the next cutover with a rollback it has already run and timed, and with criteria that let anyone call it off without an argument.
Dependency map and application inventory
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
Discovery tooling, network flow data and owner interviews combined into one map. Scheduled jobs, file shares and reporting databases are where maps usually go wrong, so we look for them specifically.
We group applications by dependency and by the business calendar. Month-end close and peak season never share a weekend with a cutover.
Servers moved with AWS Application Migration Service or Azure Migrate, databases moved to managed services where the application tolerates it. For AWS assessment and planning we use AWS Transform, which AWS names as the successor to Migration Hub.
Each connection string, API key and service account that discovery turns up goes on a list. When the workload moves, we swap it for a managed identity, an IAM role or a short-lived database credential from HashiCorp Vault.
Timed rehearsals on a copy of production, go/no-go criteria agreed in advance, and a rollback that has actually been run at least once.
capability 01 / 05in production
Discovery and dependency mapping
Discovery tooling, network flow data and owner interviews combined into one map. Scheduled jobs, file shares and reporting databases are where maps usually go wrong, so we look for them specifically.
Servers moved with AWS Application Migration Service or Azure Migrate, databases moved to managed services where the application tolerates it. For AWS assessment and planning we use AWS Transform, which AWS names as the successor to Migration Hub.
Each connection string, API key and service account that discovery turns up goes on a list. When the workload moves, we swap it for a managed identity, an IAM role or a short-lived database credential from HashiCorp Vault.
We pieced these together from Cloud Migration situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
VMware renewal quote arrives and 300 VMs need a plan
composite · not a client story
Beforethe situation
A vSphere renewal quote came in far above the last one, and the renewal date is fixed. Around 300 VMs run line-of-business apps, a few call each other by hard-coded IP address, and several keep service account passwords in web.config files.
What we dothe work
Map dependencies from discovery agents and firewall flow logs, and group the VMs into waves around the renewal date. Before cutover, replace IP literals with DNS names. Then rehost with AWS Application Migration Service or Azure Migrate, swapping each web.config password for a managed identity or a Vault-issued credential.
Afterwhere you end up
Now the wave plan says which workloads can move before the renewal and which need a short extension. Nothing lands in the cloud with a plaintext password. What stays on VMware is known and costed.
case file 02
One SQL Server reporting database that six applications write to at night
composite · not a client story
Beforethe situation
A single SQL Server instance hosts the reporting database. Discovery shows dozens of SSIS packages and SQL Agent jobs from six applications writing to it overnight, and two of those applications sit in different waves.
What we dothe work
Treat the shared database as its own wave. Catalog every SSIS package and Agent job with its source application, then decide whether the database moves first with replication back or moves last. Rehearse the cutover with DMS or native replication, timed against the nightly batch window.
Afterwhere you end up
The shared database stops being the hidden reason waves slip. Every job has an owner and a tested path, and the cutover sits in a window the batch schedule can actually tolerate.
case file 03
A cutover rolled back at 3 a.m. and nobody wrote down why
composite · not a client story
Beforethe situation
The last cutover attempt was rolled back overnight. The rollback only half worked: DNS TTLs were set to a day, so some users stayed on the new environment and wrote data there.
What we dothe work
Write a short post-incident review first. Lower DNS TTLs days before the next attempt, add go/no-go checks with named approvers, and run the full rollback in a rehearsal on a production copy, timing each step. Decide in advance what happens to data written after cutover.
Afterwhere you end up
The team goes into the next cutover with a rollback it has already run and timed, and with criteria that let anyone call it off without an argument.
How workloads move from the data center into the cloud
Discovery data maps dependencies so workloads can be grouped into waves. Each wave replicates through a migration service, gets cloud-native identity in place of stored passwords and cuts over with a tested rollback path.
Landing zonebuilt in Terraform → Migrated workloads · network and policy
Workload identityIAM roles · managed identities
Migrated workloadsrehost · replatform → Servers and VMs · rollback
Read the diagram as text
Servers and VMs → Dependency mapping: inventory
Dependency mapping → Wave plan: dependency groups
Wave plan → Replication service: schedule
Databases → Replication service: CDC replication
Replication service → Migrated workloads: cutover
Landing zone → Migrated workloads: network and policy
Embedded credentials → Workload identity: replace
Migrated workloads → Servers and VMs: rollback
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Discover
Inventory, dependency map, credential list and a first view of which applications are easy and which are not.
step 02
Plan waves
Waves sequenced by dependency, risk and calendar, each with an owner, a target design and success criteria.
step 03
Pilot
A low-risk application moved first to prove the landing zone, the tooling and the runbook format.
step 04
Migrate in waves
Rehearse, cut over, verify and hold a short stabilization period before the next wave starts.
step 05
Optimize and hand over
Rightsizing after a few weeks of real usage data, then runbooks and handover to whoever operates the environment.
you keep
What you're left with
We write these for your Cloud Migration setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Dependency map and application inventory
yours to keep
plan02
Wave plan with owners, dates and success criteria
yours to keep
runbook03
Cutover runbook and rollback plan for each wave
yours to keep
inventory04
Credential inventory with the replacement for each secret
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Cloud Migration work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you find the dependencies discovery agents miss, things like monthly jobs and file shares?
Agents see network connections while they're installed. Month-end jobs, quarter-end reports and SMB shares mapped by drive letter often don't show up in a two-week sample.
Q2
Has the rollback for each wave been executed, and how long did it take?
A rollback on paper usually fails on DNS, data written after cutover or a firewall rule. A timed rehearsal tells you whether it fits inside the change window.
Q3
If we roll back after users start working, what happens to the data they wrote?
Reverse replication, a write freeze or accepted data loss are all valid answers. The choice has to be made with the business owner before cutover night, not during it.
Q4
Which credentials move with each application, and what replaces each one?
Copy connection strings and service account passwords across as they are, and you bring the old risk into the new cloud. Each one needs a named replacement, like a managed identity, an IAM role or a credential issued by Vault.
Q5
Which AWS tooling will you plan with, given Migration Hub is closed to new customers?
AWS stopped onboarding new Migration Hub customers on 7 November 2025 and points to AWS Transform. A partner still planning around Migration Hub may not have used the current tooling.
01How long will our migration take?
It depends on the number of applications, how interdependent they are and how many change-freeze windows you have. After discovery we can give a wave plan with dates. Before it, any number would be a guess.
02Should we rehost first or refactor during the move?
When a deadline such as a data center exit is driving the move, rehosting is faster and less risky. Refactoring during migration makes sense for applications you were going to rework anyway. Most plans we'd write mix the two.
03Can we migrate without downtime?
For many databases, continuous replication brings cutover down to a short window. Some older applications still need a planned outage. We tell you which is which during planning.
04AWS Migration Hub says it isn't open to new customers. What should we use?
AWS stopped onboarding new Migration Hub customers on 7 November 2025 and points to AWS Transform, which covers strategy recommendations, instance recommendations and orchestration. Existing Migration Hub users can keep running their projects.
05Do you migrate mainframe workloads?
Yes, as part of our legacy modernization work, where the question is usually whether to rehost, refactor or replace the application.
related
Often paired with
Projects on Cloud Migration usually end up touching one of these, so they're worth a look.
