Your migration, tracked
Set your path and renewal date once. From then on this page greets you with the countdown, where you should be against the back-planned schedule, and a checklist you tick off as phases land. Nothing is uploaded; the plan lives in this browser's storage and nowhere else.
Saved only in this browser (localStorage). No account, no server, clearing site data removes it. Come back any time on this device and the plan will be here.
How to use it
A migration runs nine to twenty-one weeks; the failure mode is losing the thread between waves. This workspace is the thread: check the pilot off only when the runbook actually survived contact with real workloads, and treat a "Behind plan" state as a scheduling decision, not a moral one, you can recover slack by shrinking wave scope, or re-plan against a later renewal. The Vendor Watch feed is worth a glance on the same visit: licensing moves mid-migration occasionally change the destination calculus, and it takes thirty seconds.
What "done" means at each gate
Checkboxes are only useful if everyone agrees what ticking one means. Migrations slip most often not because a phase was hard but because it was declared finished while an unresolved question was still inside it. These are the definitions worth agreeing with your team before you start, so that a tick is a fact rather than an opinion.
- Assessment and discovery is done when you can name every workload in scope and, for each one, who owns it and what it talks to. Not when the inventory export finished. The export is the input to this phase, not its output.
- Target design is done when someone who was not in the design meetings could build the target from your document, and when your rollback criteria are written down. If nobody has written what would make you abandon a cutover mid-window, the design is not finished.
- Pilot is done when a real workload, chosen because it is representative rather than because it is easy, ran on the target through a full business cycle including a backup and a restore. A pilot that skipped the restore has not tested the thing most likely to end badly.
- Production migration is done per wave, never in aggregate. Each wave gets its own verification before the next begins, because the alternative is discovering a systemic problem after it has been applied to the whole estate.
- Validation is done when monitoring, alerting, and backup jobs cover the new platform to the same standard as the old one. This is the phase most often shortened under time pressure, and the one whose absence is felt first at 3am.
- Decommission is done when the licences are actually cancelled, not when the hardware is switched off. Paying for a platform nobody uses is a surprisingly common ending, and it quietly erases the saving the project was justified on.
Why there is no account, and what that costs you
Your plan is held in this browser's local storage and nowhere else. There is no account to create, no email to hand over, and no copy of your renewal date or estate details on any server, which matters because a migration plan is a reasonably sensitive document: it says what you run, when your contract ends, and when you will be at your most exposed.
The honest trade-off is that browser storage is per-browser and per-device. Your plan will not follow you from the laptop to the desktop, and clearing site data or browsing in a private window will lose it. If the migration is a team effort rather than a personal one, treat this page as your own working view and keep the shared source of truth in whatever your team already uses for project tracking. A sensible pattern is to use this for the weekly "where are we really" check and export the calendar events from the renewal planner into the team calendar, so the dates live somewhere everyone can see them.
If you are still choosing between destinations rather than tracking a decision you have made, start at the Alternative Finder instead, then come back here once a path is settled.