Migrate the estate, modernise what earns it, switch the old one off

Migration goes wrong when the plan is built from an asset list rather than from how the business actually uses its systems. The first phase establishes what runs, what it costs, what depends on it and what the business needs it to keep doing.

• Discovery including the unknowns. Servers, applications, databases and integrations found with platform discovery tooling alongside interviews, because the asset register is never the whole estate.
• A disposition decision per application. Retire, retain on-premises, rehost, replatform, refactor or replace, with the reasoning written down and signed off rather than assumed.
• Total cost of ownership, both sides. Current hosting, licensing, support effort and the projected run cost of each target option, stated in the same units so the comparison is fair.
• Dependency mapping before waves. Waves keep tightly coupled applications together, so a chatty pair is not split across a new network boundary and charged for the privilege.
• Risk register with dates attached. Unsupported software versions, single points of failure, missing backups, expiring hardware warranties, vendor support constraints and contract end dates.
• Landing zone readiness confirmed. Whether the platform foundation exists and is deployed from code, since migrating into an ungoverned estate means paying for the same controls twice.
• Sequenced roadmap with exit criteria. Waves, decision points and per-wave success criteria agreed before any workload moves, including what would cause a wave to be rolled back.

The target design has to be operable by your team, not only by the people who built it. We use platform services where they genuinely reduce operational load and virtual machines where the workload still needs them.

• Foundation confirmed before wave one. Environment separation, network topology and naming standards in place first, delivered under landing zone foundations rather than improvised mid-migration.
• Waves with a live rollback. Replication tooling, a rehearsed test cut-over per wave, and a rollback position that stays valid until the wave is formally signed off.
• Replatforming where the licence allows. Managed hosting, containers or functions where the code, runtime and vendor support statement permit, with load testing before cut-over rather than after.
• Databases onto managed services. Schema and compatibility assessment, a rehearsed cut-over and an agreed data validation step before the source database is retired.
• Resilience designed per workload. Zone placement, backup frequency and replication matched to the recovery objectives set during assessment, not to a single estate-wide default.
• Infrastructure as code from day one. Any environment can be rebuilt, and the difference between two environments shows up in a diff instead of in an incident.
• Decommissioning inside the wave. Each wave ends with the source system switched off or a written reason it cannot be, so the estate does not quietly double in size.

Migration is the least expensive moment to close identity, exposure and control gaps that were tolerated on-premises. Controls belong in the platform baseline, not in a remediation project after the workloads arrive.

• Identity redesigned, not copied across. Role-based access, production separated from non-production, and standing administrative rights replaced by time-bound elevation with approval.
• Guardrails inherited from the platform. Permitted regions, permitted resource types, encryption settings and mandatory tags applied at platform scope, with non-compliance reported rather than tolerated.
• Exposure reviewed at every wave. Network segmentation, private connectivity to platform services and a reviewed inbound exposure list, checked again as each wave closes.
• Secrets out of scripts. Keys, secrets and certificates moved from configuration files and deployment scripts into a managed store with rotation and access logging.
• Logging enabled by default. Diagnostic and audit logging switched on at platform level and retained for an agreed period, so evidence exists before anyone asks for it.
• Control mapping, not an attestation. Which controls the deployed configuration supports against the Essential Eight or ISO 27001, and where process still closes the gap. It is input to your own assessment, never a certification.

A modernised platform only pays back if the people running it are confident. Operating knowledge is transferred during the build rather than in a handover pack at the end.

• Runbooks for the real operations. Restore a database, fail a workload over, add an environment, rotate a secret, onboard a new application. The tasks your team will actually perform.
• Your engineers build alongside us. Working sessions inside the real environment during the build, so they have made the changes themselves before go-live rather than watched a demonstration.
• Change path agreed with the business. Who approves what, and which low-risk changes proceed without a change advisory board sitting in the way of a routine release.
• Cost ownership handed to named people. Application and business-unit owners with a monthly review rhythm and a shared definition of what counts as waste.
• Decommissioning plan with evidence. What must be proven before hardware, licences and support contracts are released, agreed with whoever signs the release off.
• Go-live readiness against agreed criteria. Measured against the criteria set during assessment, with every open item given an owner and a date rather than a status colour.

Delivery is the beginning, not the end. Once the platform is live we can keep operating it with you under an agreed service schedule, or step back into an advisory role as your team takes it on.

• Health, capacity and error monitoring. Platform health, capacity and error rates watched, with alerts routed to the contacts and channels named in your service schedule.
• Patching against an approved calendar. Operating systems, runtimes and managed service versions updated on a cadence planned against a maintenance calendar you approve in advance.
• Restore tests reported, not assumed. Scheduled backup and restore verification, with the test result sent to you rather than recorded as having presumably passed.
• Monthly cost review with actions. Spend by application and business unit, forecast variance, and specific rightsizing or commitment recommendations with the saving quantified before you decide.
• Drift and waste reported. Resources outside policy, untagged spend and privileged access that has not been used, each routed to a named owner.
• One prioritised improvement backlog. Carried between reviews and prioritised with you on business impact rather than on technical preference.