A cloud migration checklist earns its place only when every line on it can be marked true or false about your own infrastructure, and the verdict lies with a designated individual documented beside that line. That is the precondition, and at the point of selection it is the only one that matters. Until that is met, the document in front of you is a reading list, and weighing one reading list against another spends assessment budget without reducing exposure. Nothing below introduces a provider, a template or a migration approach before that test is applied, because none of those choices changes what a step with no responsible individual does to a migration tranche six weeks later.
The failure mechanism is well documented. Cloudaware's cost guide observes that forecasts usually assume service selection is the hard part, when the pressure actually comes from undocumented dependencies, hybrid operation and the work of proving a workload safe to move. Those pressures reach the plan through gaps in assigned responsibility rather than through gaps in the service catalogue, and a checklist that does not force them into the open will be completed on schedule while the migration stays exposed. The depth resides elsewhere on this site: assessment, placement and sequencing each have their own treatment. This page is the gate list, which tells you which checks to run and at which point in the work they cease to be useful.
Checks you run against the document itself, before you adopt it
These tests apply to a candidate document rather than to your infrastructure, and each one can be resolved now.
- Every line assigns a single responsible individual, rather than a team, a function or a role title with no holder.
- Every line defines an outcome that can be observed, so that ticking it becomes a claim someone can be challenged on.
- Every line logs when it was last checked, because a list completed in March speaks only for March.
- The monetary lines separate project cost from steady-state run cost, since a document that merges them cannot support a business case.
- The document admits what it does not address.
Atlassian is candid about the boundary of its own tooling:
The Jira Cloud Migration Assistant automatically reviews your data for common errors. However, it won't check for everything, so you'll also need to run through this pre-migration checklist before starting a migration.
Candidate documents differ in shape, and the shape shows where each one earns its keep. Atlassian's pre-migration checklist runs to 24 numbered items split across mandatory, recommended and optional tiers, and it supplies SQL and shell verification wherever human judgement would otherwise suffice. Device42's checklist is organised as 12 sublists moving from objectives and infrastructure assessment through to governance and post-migration review, which makes it strong on inventory and dependency mapping and light on the commercial decisions. Apogee Corporation's twelve-step version runs from defining objectives to continuous optimisation, and it aims at a buyer who intends to hand the work to a partner. Globtier's five-phase version compresses the same ground into assessment, workload readiness, data and security, cutover, and post-launch tuning, which suits a small infrastructure and thins out on governance.
Each candidate breaks down at a different point, and the point at which a candidate breaks down is the point at which your own move will break down.
Converting whichever document you adopt into something usable takes five steps, and they apply regardless of source.
- Assign one responsible individual to every line, and delete any line that cannot have one.
- Attach an observable test to each line, expressed as a measurable value or an artefact that already exists.
- Split every cost line into project cost and run cost, then re-derive the total.
- Add the lines the source omits for your sector, your regulator and your data classes.
- Set a re-check interval, so the completed document expires instead of being filed as evidence.
Checks made in the fortnight before a migration tranche is scheduled
The window between planning and execution is where assumptions are still cheap to correct.
- The tranche has a logged abort trigger, and the individual empowered to invoke it is identified on the run sheet.
- Both the source and target environments have a responsible individual and a cost code for the overlap window.
- The rollback has been executed at least once outside production, rather than set down in a runbook and trusted.
- Firewall and proxy allowances for the provider's control-plane domains are verified, since a blocked domain breaks a migration rather than slowing it.
- Dependency mapping is current to within a fortnight, because integration work is the least predictable driver in every published cost model.
Threshold values belong in this section, because a threshold is what converts a line into a test. Cloudaware's cost guide places small workload migrations between $20,000 and $100,000, mid-market work between $100,000 and $500,000 and above, and enterprise multi-tranche efforts from $500,000 into the millions, with labour, data movement, integration and the double-run window as the dominant drivers ahead of compute and storage. Mission Cloud reaches the same conclusion from the other direction, listing overlapping services during cutover among the hidden costs that catch organisations out, because the old and new stacks frequently run in parallel for weeks or months. A tranche with no figure attached to its overlap window has no abort trigger either, since no individual can tell when the spend has outgrown the reason for the move.
Tooling thresholds are equally concrete. In a Jira Data Center environment, Atlassian's pre-migration checklist establishes the JVM heap at a minimum of 4096m, the open files limit close to 32768, and the database connection pool above the default maximum of 20, with 40 as a working figure during migration. Verification runs as a command rather than as a discussion:
grep -i "xmx" <Support Zip Location>/application-properties/application.xml
grep -i "<max-file-descriptor>" <Support Zip Location>/application-properties/application.xml
Checks made within the cutover window
Cutover checks are short-lived and unforgiving, and the list should be short in proportion.
- The maximum execution time for each step is set down before the step begins.
- Each step has a rollback that has been timed, rather than drafted and trusted.
- One individual has the power to abort the run, and the delivery lead does not share it.
- Data synchronisation passes are counted, so that a repeated sync becomes a visible cost rather than a surprise.
- The change record, the access change and the monitoring change land together, leaving nothing for the following morning.
Checks made in the first thirty days
- Every temporary environment created for the migration has been identified and given a decommission deadline.
- Every resource has the tag that maps it to an application, a responsible individual and a cost allocation code.
- Access reflects the new environment rather than the old one, with multi-factor authentication enforced and standing privileges removed.
- Performance baselines exist for the workloads now in production, measured under production traffic rather than under migration-phase load.
- The first invoice has been checked against the run-cost model line by line.
Review at the ninety-day mark, and the lines it should delete
- The run rate matches the model, or the gap is explained by a logged change rather than by drift.
- The savings timeline has been restated using real figures, since a delayed cutover moves the point at which savings appear.
- Every workload's migration approach still matches the classification assigned at assessment, and any deviation has been documented and approved.
- Any check that has never once been marked false is either redundant or badly framed, and should be replaced with a test that can break.
- The next tranche inherits the corrections, so the list improves instead of being re-derived from the same template.
What this page settles, and what it hands on
This page settles which checks to run, when to run them, and what makes a check worth keeping. It hands on the technical depth: assessment methods, placement decisions, sequencing models, and the commercial modelling that converts a threshold into a business case. Each of those has a dedicated page on this site, and none of them can be executed well against a checklist that has no responsible individual beside each line.
