Cloud
The full domain, and the other capabilities within it.
Cloud Migration
Moving the workload is the small part. Knowing what it talks to is the rest.
What this is
Cloud migration is the work of moving applications and data onto a cloud platform with the dependencies, sizing and cutover sequence established first. It covers the inventory, the landing zone the workloads arrive into, and the runbooks that move them.
The failure mode we see most is a migration planned per server rather than per application. Servers move cleanly and the application breaks, because a batch job, a licence server or a hard-coded IP address was never in anyone's inventory. Dependency mapping is not paperwork; it is what decides the wave order.
When you need it
If more than one of these is true, this is usually the right place to start.
- A hardware refresh or a data centre lease renewal is forcing a decision this budget cycle.
- Nobody can produce a current list of what runs where and what it depends on.
- An earlier lift-and-shift landed workloads in the cloud and the bill has not behaved as expected.
- A cloud account exists but was created ad hoc, with no landing zone, naming or identity model behind it.
What the scope covers
- Application inventory and dependency mapping, built from discovery data rather than from what the CMDB claims.
- Sizing and target platform selection per workload, including the ones better left where they are.
- Landing zone build: account or subscription structure, network connectivity, identity federation and baseline policy.
- Wave planning, cutover runbooks and rollback criteria for each wave.
- Post-migration validation, handover of operational runbooks, and decommissioning of the source estate.
What you receive
| Deliverable | What it contains |
|---|---|
| Dependency map | Application-to-application and application-to-infrastructure dependencies, with the ones observed on the wire flagged separately from the ones people told us about. |
| Landing zone | Accounts, network, identity federation and policy baseline built as code, so the environment can be rebuilt rather than remembered. |
| Wave plan | Workloads grouped into migration waves by dependency and risk, with the sequence and the reasoning behind it written down. |
| Cutover runbooks | Per-wave steps, owners, timings, validation tests and the rollback decision point, rehearsed before the live window. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Cost per workload against the pre-migration baseline, tracked monthly rather than at the end.
- Waves completed inside their planned window, with a recorded reason for each one that was not.
- Application validation tests passing after cutover, counted per application rather than per server.
Questions we are asked
Should we lift and shift, or re-architect?
Both, on different workloads. Lift and shift is the right answer when the deadline is a lease expiry and the application is stable. Re-architecting earns its cost on systems you change often or that scale badly. The decision belongs per application, and making it once for the whole estate is what produces the disappointing bills.
How long does a migration take?
It depends on how much of the estate is documented and how many applications are shared services. Discovery is usually the long pole, not the moving. A useful early signal is how quickly the inventory stops producing surprises; until it does, wave planning is guesswork.
Will the cloud be cheaper?
The honest answer depends on the workload profile and on what you do after the move. Steady-state, always-on systems moved as they are often cost more than the depreciated hardware they left. Savings come from right-sizing, commitment planning and switching things off, which is a discipline rather than an outcome of the migration itself.
What do we do with workloads that cannot move?
Leave them, and design for it. Regulatory constraints, licensing terms, latency to a physical system or an unsupported operating system are all legitimate reasons to keep something on-premises. That decision turns the project into a hybrid design, which is a different set of connectivity and identity choices made deliberately rather than by accident.
How do you handle the data?
Data volume and change rate set the method. Small, static datasets copy inside a window. Large or continuously changing ones need replication running ahead of the cutover with a final delta at the switch. The number that matters is how long the source can stay read-only, and that is a business answer before it is a technical one.
What happens if a cutover fails?
Every wave has a rollback point and a time by which the decision to use it must be made. Rollback stops being cheap once the target has taken writes, so the runbook names that moment explicitly. Waves whose rollback is genuinely impractical are identified during planning, not at three in the morning.
Continue reading
Hybrid Cloud
Landing zone, private connectivity and one identity and policy model spanning on-premises and cloud, so workload placement becomes a decision.
Cloud Optimization
Tagging, cost allocation, right-sizing and commitment planning for cloud spend you can attribute to a named owner and explain line by line.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.