The first useful artifact is not a target architecture diagram. It is a map of the current bill, the workloads behind it and the decisions that would make the migration worth doing. Without that map, a lift-and-shift can reproduce old constraints at a higher monthly cost.

Start with the bill

Separate compute, storage, data transfer, managed services, support and engineering time. Mark which lines are driven by traffic, retention or idle capacity. A single total hides the decisions that can actually change it.

  • Run rate and the largest cost drivers, not only the monthly total.
  • Data transfer, egress and cross-region traffic.
  • Storage growth, snapshots, backups and retention rules.
  • Managed services and the engineering work they replace or add.
  • Licences, support plans and the cost of leaving the current platform.

Decide what should move

  • Latency, availability and the failure modes you accept.
  • Data gravity: where data lives, who owns it and what moving it costs.
  • Security, privacy and data-residency constraints.
  • The team’s ability to operate the target platform, not only deploy to it.
  • Reversibility: how you would move back or change provider later.

Migration checklist

  1. Inventory applications, owners, dependencies and data flows.
  2. Document current runbooks, alerts and known failure modes.
  3. Record the target architecture and what is intentionally not changing.
  4. Plan data migration, validation and reconciliation before cutover.
  5. Rehearse cutover and rollback on a representative environment.
  6. Define success, abort and rollback criteria before the migration window.
  7. Set budgets, tags, alerts and an owner for the new run rate.
  8. Decommission the old environment and access only after the evidence is complete.

Cost controls that survive

  • Tag by product, environment and owner so the bill maps to a decision.
  • Review idle, oversized and orphaned resources on a fixed cadence.
  • Treat retention, backups and logs as product decisions, not defaults.
  • Measure unit economics: cost per tenant, order, job or active user where meaningful.
  • Keep a documented exit path instead of assuming the current provider is permanent.

What good looks like

A good migration leaves a smaller list of unknowns: clear ownership, tested recovery, a bill that can be explained and a path to change the architecture without another full migration. The target is not “we are on the cloud”; it is “we can operate this system deliberately.”

See Cloud & DevSecOps, what drives custom software cost or discuss your project.