Cloud Modernisation

Modernisation 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 of servers, applications, databases and integrations, including the ones missing from the asset register, using platform discovery tooling alongside interviews with the people who run them.
• A disposition decision for every application (retire, retain on-premises, rehost, replatform, refactor or replace) with the reasoning written down and signed off.
• Total cost of ownership comparison covering current hosting, licensing, support effort and the projected run cost of each target option.
• Dependency mapping so migration waves keep tightly coupled applications together and avoid splitting a chatty pair across a new network boundary.
• Risk register covering unsupported software versions, single points of failure, missing backups, expiring hardware warranties and vendor support constraints.
• A sequenced roadmap of waves, decision points and per-wave success criteria, agreed before any workload moves.

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.

• Landing zone build with the management group or organisational unit structure, environment separation, network topology and naming standards fixed before the first workload lands.
• Migration waves executed with replication tooling, a rehearsed test cut-over per wave, and a rollback position that stays valid until the wave is signed off.
• Application replatforming onto managed hosting, containers or functions where the code and licensing allow, with load testing carried out before cut-over rather than after.
• Database migration onto managed database services, including schema and compatibility assessment, a rehearsed cut-over and an agreed data validation step.
• Resilience design per workload, matching zone placement, backup frequency and replication to the recovery objectives set during assessment.
• Infrastructure defined as code from the first environment, so any environment can be rebuilt and the difference between two environments is visible in a diff.

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

• Identity design with role-based access, separation between production and non-production, and standing administrative rights replaced by time-bound elevation with approval.
• Policy guardrails applied at platform level covering permitted regions, permitted resource types, encryption settings and mandatory tags, with non-compliance reported rather than silently tolerated.
• Network segmentation, private connectivity to platform services, and a reviewed inbound exposure list so nothing becomes reachable from the internet by accident.
• Secrets, keys and certificates moved out of configuration files and deployment scripts into a managed store with rotation and access logging.
• Diagnostic and audit logging enabled by default at platform level and retained for an agreed period, so evidence exists before anyone asks for it.
• Control mapping to the frameworks you are aligning to, such as the Essential Eight or ISO 27001, setting out which controls the platform configuration supports and where process still has to close the gap. The mapping is input to your own assessment, not an attestation.

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 operations your team will actually perform: restore a database, fail a workload over, add an environment, rotate a secret, onboard a new application.
• Working sessions with your engineers inside the real environment during the build, so they have made the changes themselves before go-live.
• A change and approval process agreed with the business, defining who approves what and which low-risk changes proceed without a change advisory board.
• Cost ownership handed to named application and business-unit owners, with a monthly review rhythm and a shared definition of what counts as waste.
• A decommissioning plan for the source environment, including the evidence required before hardware, licences and support contracts are released.
• Go-live readiness review against the criteria agreed during assessment, with every open item given an owner and a date.

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.

• Monitoring of platform health, capacity and error rates, with alerts routed to the contacts and channels named in your service schedule.
• A patching and update cadence for operating systems, runtimes and managed service versions, planned against a maintenance calendar you approve in advance.
• Scheduled backup and restore verification, with the test result reported to you rather than assumed to have passed.
• Monthly cost review covering spend by application and business unit, forecast variance, and specific right-sizing or commitment recommendations with the saving quantified before you decide.
• Governance drift reporting listing resources outside policy, untagged spend and privileged access that has not been used.
• A continuous improvement backlog carried between reviews and prioritised with you on business impact rather than technical preference.