Cloud migration should start with a business and operational objective: improved resilience, reduced maintenance, access to a managed service or a change in capacity. Moving infrastructure does not automatically reduce cost or improve every workload.
Choose a strategy per workload
AWS describes seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. See its cloud migration overview. A portfolio can use several strategies rather than forcing every application through the same transformation.
Rehosting can be a legitimate response to a datacentre exit or a time constraint. Re-architecting may unlock benefits, but it adds delivery risk and cost. Neither approach has an inherently positive or negative return without the workload context.
Inventory dependencies and economics
Map application owners, integrations, data stores, network paths and licensing. Identify dependencies that could prevent a workload from moving independently. Capture current demand and operational costs before estimating the target environment.
Include compute, storage, network transfer, backups, support, licences and engineering effort. Compare normal load, peaks and failure scenarios. A serverless service can reduce some server-management work while introducing its own limits and operational responsibilities; it is not automatically suitable for every workload.
Managed databases still require planning for schema compatibility, extensions, access controls, replication and cutover. Migration to a managed service is not an instantaneous substitution for an existing database.
Validate the target design
Agree on recovery objectives, security controls, data location and service limits. Verify that required features exist in the chosen region and configuration. Cloud providers’ AI and other services are not universally interchangeable or feature-identical.
Use a representative pilot to assess performance, operating effort and costs. Record the assumptions that remain unproven before committing the rest of the portfolio.
Make three workload decisions separately
Illustrative inventory: retain a stable licensed ERP until its supported migration route is confirmed; rehost a compatible internal reporting service if its dependencies and recovery path can be verified; replace an unsupported public upload component when its risk and replacement scope are established. These are conditional decisions, not a claim that a single cloud strategy fits every system.
For an order system cutover, finance approves the reconciled transaction count, operations approves the open-order list and the release owner authorises the switch. Set the last permitted write, final synchronisation and rollback trigger in advance. If new-system writes cannot be reconciled back, “switch the DNS back” is not a recovery plan.
Use a synthetic first-year comparison to expose hidden work: MYR 1,000/month old hosting versus MYR 700/month new services saves MYR 3,600 annually. MYR 5,000 migration plus MYR 1,000 parallel running exceeds that first-year saving before staff effort. These invented inputs are arithmetic, not cloud prices. Replace them with quotes and include licences, network transfer, backup and operations.
Frequently asked questions
Can we migrate without downtime?
Only promise the interruption window supported by a rehearsed cutover for the actual data and write pattern. Name the business approver and the person authorised to stop the release.
What should we fund before a migration quote?
Resolve the dependencies that could change the strategy. An architecture audit should return a workload decision, evidence gaps and cutover risks; use the cost brief to compare the complete lifecycle.
Plan cutover and operation
For a hypothetical order-management system, record the application owner, database, payment connection, scheduled jobs and downstream reports in one dependency map. A move is ready to price only when the team can answer where writes stop, how records are compared, who decides to resume traffic and what happens if the new system has already accepted orders. These questions are more useful than assigning every workload the same “lift and shift” label.
| Decision record | Evidence to collect before a pilot |
|---|---|
| Workload boundary | Users, data stores, integrations and peak transactions |
| Recovery | Backup restore result, data reconciliation method and decision owner |
| Cost | Current bill, target estimate, migration effort and operating time |
Define data synchronization, validation, ownership and a recovery decision point. The appropriate method depends on allowable downtime and consistency requirements. Avoid promising zero downtime without a design and evidence that support it.
After cutover, monitor business transactions as well as infrastructure health. Confirm backups and operational access, and retire old resources only after the agreed validation and retention requirements are met.
An architecture audit can identify which workloads should move, which should remain and which assumptions need a pilot before a migration commitment.
Place the migration inside a broader digital transformation roadmap when it changes staff workflows or ownership across teams. For a platform-generated application, our Manus handover planning guide uses a hypothetical example to identify authentication, data, file and deployment dependencies before estimating a move.
