Most AWS migration disasters start the same way. A CTO gets told the move will be a straightforward project, the team lifts and shifts a stack into the cloud, and six months later they're paying for old problems with new infrastructure. The bill changes, the outage patterns change, but the underlying mess stays put.
That's the wrong mental model for AWS migration. In Australia, the public-sector signal is already clear, cloud adoption has moved well past experiments, with more than 140 Commonwealth, state, and territory agencies already using AWS to support service delivery across transport, health, education, and tax, according to the Digital Transformation Agency's January 2025 announcement, and the same environment now expects value, reliability, and security to be managed at scale. The right response is a program, not a one-off cutover.
Table of Contents
- Why AWS Migration Is a Program, Not a Project
- Discovery and Assessment That Actually Informs Strategy
- Choosing Between Rehost, Replatform, and Refactor
- Phasing the Migration and Running a Real Pilot
- Runbooks, Cutover, and Rollback You Can Trust
- Cost Optimisation and Governance After Cutover
- Post-Migration Support and What to Do Next
Why AWS Migration Is a Program, Not a Project
A project mindset asks, “How fast can we move servers?” A program mindset asks, “What business outcome justifies each wave, and how do we prove it after the move?” That difference matters because the first approach usually optimises for motion, while the second optimises for control, accountability, and measurable value.
The Australian market already reflects that reality. The Australian Government signed a whole-of-government AWS agreement in 2019 that gave agencies access to over 165 AWS cloud services and was valued at $39 million, explicitly to remove the need for separate tenders and streamline adoption across federal agencies, universities, and government-controlled bodies Datacenter Dynamics. A later DTA arrangement again framed AWS use as a common channel for phased migration rather than a bespoke purchase every time DTA media release.
The early decisions you make before tooling
Before anyone buys migration tooling, a CTO has to lock four things down. First, which business outcomes justify the move. Second, which workloads are in scope and which ones are not. Third, how governance will work across regions and compliance boundaries. Fourth, what event closes a wave, not just what task list finishes.
Practical rule: if a workload can't be tied to an owner, a business service, and a compliance classification, it isn't ready to migrate.
That's the difference between program-level governance and project-level execution. Funding cycles, executive sponsorship, and regulatory alignment belong to the program. Tickets, runbooks, and cutover windows belong to the project team inside that program.
If you treat the move as a quick project, you'll cut corners on assessment and call it speed. If you treat it as a program, you'll sequence the work, set gates, and keep the business honest about what value is being created. That's the framework the rest of this playbook follows, and it's the only one that holds up when compliance, cost, and operational continuity all matter at once.
For teams planning the move with external support, the right starting point is a structured cloud migration engagement, not a pile of servers and good intentions. A practical overview is available through Cloud Migration Services.
Discovery and Assessment That Actually Informs Strategy
Discovery is not a data-dump exercise. If it doesn't answer the next decision, it's just admin work with a spreadsheet attached. Good assessment produces artefacts that a CTO can use to decide scope, sequencing, risk, and cost.
The first artefact is a workload inventory. It should link every application, batch job, database, and interface to a business service and an owner. The second is a dependency map, because hidden coupling is what breaks clean cutovers. The third is a cost and performance baseline that later proves whether migration improved anything. The fourth is a readiness scorecard covering security, compliance, and operational maturity.
What each artefact is for
| Artefact | Owner | Decision It Enables |
|---|---|---|
| Workload inventory | Application owner | Whether the workload is in scope and who signs off |
| Dependency map | Solution architect | How to group systems into migration waves |
| Cost and performance baseline | Finance or platform lead | Whether the migration business case still holds |
| Readiness scorecard | Security and operations lead | Whether the workload can move now or needs remediation |
Don't trust the CMDB blindly. Don't treat an agentless scan as the full picture either. Both can miss the messy parts that matter most, especially shared services, legacy integrations, and unspoken operational dependencies. If the assessment can't expose those issues, it can't inform strategy.
AWS also continues to publish Australia and New Zealand public-sector guidance as a live offer for federal, state, and local government use, which reinforces that assessment needs to be tied to current controls and service scope, not stale assumptions AWS government page.
Good discovery gives you facts you can defend in a steering committee, not a stack of diagrams nobody can use.
Use the inventory to define scope, use the dependency map to group workloads, use the baseline to measure post-move value, and use the scorecard to decide whether a workload is ready for the cloud or needs pre-work first. If any of those artefacts is weak, the migration strategy will be weak too. That's why assessment is not a preliminary task, it's the point where the migration strategy becomes real.
Choosing Between Rehost, Replatform, and Refactor
Stop asking which option is fashionable. Ask which one matches the workload, the deadline, the compliance profile, and the cost of carrying technical debt forward. That's the only decision matrix that matters.
Rehost moves binaries and configuration with minimal change. Replatform keeps the application logic but swaps in managed services, such as moving a database layer onto a managed relational service. Refactor changes the architecture so the workload can use cloud-native patterns like containers, serverless components, or event-driven design.
Decision criteria that actually matter
| Criterion | Rehost | Replatform | Refactor |
|---|---|---|---|
| Business urgency | High when speed matters | Medium when you need some improvement without delay | Low to medium because it takes longer |
| Compliance constraints | Useful when control must stay close to the source design | Better when managed services help with controls | Hardest, because the architecture and controls change together |
| Licensing exposure | Can preserve existing licences short term | May reduce waste if licensing aligns with managed services | Can help, but only after a real redesign |
| Cost of leaving debt intact | Highest, because debt comes with you | Moderate, because some debt gets removed | Lowest over time, if the redesign is justified |
A monolithic ERP usually starts with rehost or selective replatforming, not a dramatic rewrite. A customer-facing web stack often deserves replatforming first, especially if the database layer is the bottleneck. Batch analytics can be a good refactor candidate if the current design is expensive to scale. Legacy messaging usually needs a staged approach, because the interface dependencies are where the risk lives.
Don't refactor just because the word sounds modern. If the app is brittle, highly regulated, or tightly coupled to old licensing, a rewrite can slow the programme down and create more outage risk than it removes. On the other hand, don't rehost forever and pretend that's strategy. Rehosting is sometimes the right first move to buy runway, but it's not an end state.
For teams moving off fragile hosting estates, Migrating from Shared Hosting to AWS is often the first conversation, because the business problem is usually reliability and control, not architecture purity.
Phasing the Migration and Running a Real Pilot
Migration waves should follow business risk, not data-centre geography. Group workloads by business criticality, dependency density, and compliance footprint, because those are the factors that decide how much blast radius a wave carries. If you sort workloads by server rack or ticket queue, you're organising by convenience instead of risk.
Start with non-production and low-risk estates. Use them to validate identity, network patterns, logging, access controls, and deployment paths. Move to tier-2 systems only after the team has already handled one real wave without improvising.
What a real pilot looks like
A pilot is not a synthetic test environment with toy traffic. It must be a real workload with real users, because that's the only way to prove monitoring, alerting, incident response, and support handoff under pressure. A pilot should exercise the full runbook, including the fallback path.
Each wave needs an exit gate. Don't close a wave until performance parity has been checked, security has signed off, and rollback has been rehearsed. If any of those gates fails, the wave stays open.
The pilot should expose the ugly bits early. If a process breaks on pilot day, it would have broken on production day too.
Australian public-sector examples show why this matters. IP Australia's 2026 tender sought a partner to migrate selected on-premises ICT workloads to AWS by June 2026, which shows that delivery is being run against fixed deadlines, not open-ended cloud ambition Australian Tenders. Fixed dates sharpen discipline, but they also punish vague planning.
A serious wave plan assumes that each wave amends the runbook before the next one starts. That's how you reduce repeated mistakes. It's also how a multi-year program keeps learning instead of repeating the same cutover failure in different clothes.
Runbooks, Cutover, and Rollback You Can Trust
Cutover day exposes whether the team engineered a migration or just moved tickets around. A generic checklist won't save you. The runbook has to be specific to the workload, the dependencies, and the failure modes you already know about.
Document pre-cutover prerequisites, the exact sequencing, validation steps, named owners, and timeboxes. Include freeze windows so nobody changes upstream dependencies while the move is happening. Put communication plans in writing so the help desk, business users, and incident managers all know what's happening and when.
What belongs in the cutover runbook
- Freeze controls: Lock change windows for dependent systems before the migration begins.
- Go or no-go gates: Define the exact checks for data integrity, latency, and error budgets.
- Validation steps: Confirm application health, data consistency, and user access before declaring success.
- Owner mapping: Assign one person per action, not one team per section.
- Rollback trigger: State the conditions that force a revert, not just the ones that suggest caution.
Rollback also needs rehearsal. That means testing the reversal of DNS, database pointers, and application configuration before production day, not after something has already failed. Define the maximum tolerable rollback window in advance and stick to it.
AWS migration teams in Australia often trip over late security work. The common mistake is treating accreditation as a last-minute tick box, which is exactly how you end up discovering control gaps during the cutover window instead of before it. If you want a reminder of the kinds of errors that show up in small and mid-market environments, Common AWS Mistakes SMEs Make is a useful comparator, even if your estate is larger.
Testing must happen in the target environment. Load testing, failover testing, and security scanning need to run where the workload will live, because source-environment success doesn't guarantee destination-environment safety. Add observability from day one, with synthetic checks, tracing, and log baselines, so anomalies surface within minutes instead of after the business has already noticed them.
A cutover that depends on hope is a bad cutover. A rollback you've never rehearsed is not a rollback plan. Those two statements sound blunt because they're true.
Cost Optimisation and Governance After Cutover
Cost control is not a clean-up task. It's part of the operating model from wave one, or you'll discover too late that the cloud migration improved agility while increasing waste. Governance works the same way. If you leave controls until after cutover, drift starts immediately.
Build FinOps into the migration runbook. Tagging standards should be in place before workloads move, not after. Showback reporting should begin as soon as the first wave goes live. Rightsizing reviews should be scheduled for 30, 60, and 90 days after cutover so teams can catch oversizing while the memory of the migration is still fresh How much does an AWS migration cost in Australia.
FinOps and governance levers after cutover
| Lever | When to Apply | Owner |
|---|---|---|
| Tagging standards | Before first cutover | Platform lead |
| Showback reporting | Immediately after go-live | Finance or cloud ops |
| Rightsizing review | 30, 60, and 90 days post-cutover | Cloud engineer |
| Storage tier review | After usage stabilises | Infrastructure lead |
| SCP guardrails | Before broad production access | Security lead |
| Config and Security Hub baselines | As workloads enter steady state | Security and compliance |
Use Savings Plans, Reserved Instances, and Spot where utilisation patterns justify them. Review storage tiers so cold data isn't sitting on hot storage, because that's how people create unnecessary cost without noticing it in the first month. Governance should rely on preventive guardrails, not cleanup after someone has already over-provisioned access or drifted from policy.
AWS Organisations SCPs, IAM least-privilege baselines, Config rules, and Security Hub baselines should all trace back to the assessment findings, not to a generic template somebody copied from another team. That keeps governance aligned with actual workload risk instead of imagined risk. It also gives the steering committee a clean line from migration choice to operational control.
Datacom's 2025 Australian cloud report found that fewer than half of organisations believe their cloud investments delivered the promised benefits Datacom. That gap is the warning sign. If you don't track value after cutover, you'll only know you migrated, not whether you improved anything.
Post-Migration Support and What to Do Next
A migration is not finished when the workload starts up in AWS. It's finished when the support model stabilises, the value is visible, and the next set of improvements has been captured. That's why I push for a 30-60-90 day support window with named owners and a clear handover into steady state.
The stabilisation checklist should cover error budget consumption, latency baselines, cost variance versus forecast, and ticket backlog burndown. If those measures are drifting in the wrong direction, the programme still has work to do. If they're stable, the Cloud Centre of Excellence can take over ongoing governance and improvement.
Handover artefacts that matter
- Updated architecture diagrams: Show the target-state design, not the pre-migration assumption.
- IAM and network topology: Make access boundaries and connectivity visible to ops teams.
- Runbooks and IaC repositories: Keep manual steps out of the critical path.
- Known-issues register: Record unresolved defects, workarounds, and follow-up owners.
- Value-realisation scorecard: Track migration ROI, realised savings, modernisation backlog, and compliance posture.
The post-migration phase is also where monitoring debt gets exposed. If you need stronger observability on the new platform, Enterprise Application Monitoring and Debugging is the right kind of discipline to bring in, because post-cutover support is mostly about seeing issues before users do.
If you're engaging a delivery partner, scope an AWS Migration Acceleration Program style engagement around assessment, wave planning, and post-cutover validation. Ask for evidence of comparable migration waves, not just landing zone work. Ask who wrote the runbooks, who handled rollback testing, and how value was measured after go-live.
A partner who can't explain how they closed a wave and proved the outcome probably hasn't run a serious migration programme. You need someone who can do the assessment, sequence the work, and stay accountable after the cutover noise dies down.
If you're planning an AWS migration and want a partner who can handle assessment, phased execution, and post-cutover governance with real delivery discipline, speak to Continuum Solutions. We design migration programmes around workload risk, compliance, and measurable operating outcomes, not just technical cutover. Visit Continuum Solutions to start the conversation.