Why the assessment decides how the migration goes
Most troubled migrations fail before the first server moves. The estate was larger than the spreadsheet said, a batch job depended on a file share nobody remembered, or a database licence did not allow the target platform. Each of these is cheap to find during assessment and expensive to find during cutover.
A readiness assessment is the first stage of our cloud migration service. It produces the evidence that the migration roadmap is built on, and it shapes the design of the landing zone. Skipping it does not save time. It moves the discovery work to the most stressful part of the project.
What a good assessment contains
- A reconciled inventory: servers, databases, storage, network devices, SaaS in use and the owner of each.
- Dependency groups: sets of systems that must move together because they talk constantly.
- A per-workload record of constraints: compliance scope, data residency, licensing, latency, support status.
- A 6Rs classification with a written reason and a named risk.
- A list of unknowns, each with an owner and a date to resolve it.
If an assessment cannot tell you why a workload is classed as replatform rather than rehost, it is not finished.
The 6Rs in practice
| Strategy | What it means | Typical fit |
|---|---|---|
| Rehost | Move the VM as it is | Stable commercial software, tight deadlines, data centre exit |
| Replatform | Move with a small change, for example to a managed database | Databases, message brokers, simple web tiers |
| Refactor | Redesign for cloud native services | Systems with real scaling or release pain |
| Repurchase | Replace with SaaS | Email, CRM, ticketing, internal tools |
| Retire | Switch off | Unused or duplicated systems |
| Retain | Leave where it is for now | Site-tied hardware, licence limits, imminent retirement |
Rehost is often the right first move even when refactor is the long-term goal. Moving first and modernising later separates two risky changes. The mistake is treating rehost as an end state without checking the running cost, which is why the cost optimisation stage is part of the programme.
How the dependency mapping works
Documentation of dependencies is usually wrong in one of two ways: it is out of date, or it covers application calls but not the quiet ones such as DNS lookups, NTP, LDAP binds, backup agents and monitoring. We read dependencies from traffic.
For a VMware estate, that can mean enabling flow collection for a few weeks and aggregating it. On the source side, a quick view of established connections on a candidate server is often enough to start a conversation:
# Established connections grouped by remote address and port
ss -tn state established '( sport = :443 or dport = :1433 or dport = :5432 )' \
| awk 'NR>1 {print $4}' | sort | uniq -c | sort -rn | head -20
This is a starting point only. Monthly and quarterly jobs will not appear in a two week sample, so we ask owners about batch schedules and extend the capture window across a month end where finance systems are involved.
Decisions and trade-offs
Agent-based or agentless discovery
Agentless discovery through the hypervisor is quick and light, and gives sizing and inventory. It cannot see inside the guest well enough for dependencies. Agent-based discovery sees processes and connections but needs change approval on each server. We usually start agentless, then add agents to the application groups where dependency questions remain.
Sizing from utilisation, not from the existing VM
On-premises servers are often oversized because hardware was bought for peak plus growth. Sizing the cloud instance from observed CPU, memory and disk behaviour avoids paying for headroom you never used. Collect enough history to include the busy periods, and keep a margin for unusual events.
Where not to over-invest
Not every workload needs the same depth of analysis. A small internal tool that is being retired does not need a month of dependency capture. We spend effort where the risk is: customer-facing systems, databases, anything with compliance scope.
Common failure modes
- A spreadsheet treated as truth. We reconcile it against discovery output and flag differences rather than trusting either source alone.
- Compliance found late. We record data classification and regulatory scope at the start, so region choice and encryption design are known before the security baseline is written.
- Licensing surprises. Some database and middleware licences are tied to sockets, cores or specific hosting terms. We list them and ask the vendor or your licensing contact before assuming portability.
- Everything marked refactor. Ambition is good, but a programme where every workload needs redesign never finishes. We push back and sequence modernisation after the move.
- Orphaned workloads. Systems with no owner are a risk either way. We name an owner or recommend retirement.
Delivery and handover
You receive the work as documents and data you can keep: the inventory in a spreadsheet or a repository, dependency groups, the classification table and a short written summary of the main risks. Where it helps, we encode the target environment decisions as infrastructure as code later in the programme, but the assessment itself needs no tooling to stay in your account.
We run a review session with application and business owners before closing. This is the point where disagreements are cheapest to settle, and it is where we most often change a classification.
How to tell it is working
A useful assessment shows up in the next stage. Every workload has an owner and a strategy. Dependency groups are small enough to plan waves around. Nobody is surprised during rehearsal by a system that was not in the inventory. The list of open unknowns shrinks each week.
If you want an honest read on what your estate would involve, book a consultation and we will scope an assessment with you. For the wider picture of how we run programmes, see engagement models.