Migrations fail on the things nobody listed: an undocumented dependency, a licence that does not transfer, a batch job on a machine everyone forgot. A pilot is how you find those while they are still cheap.
Choose the right pilot workload
- Representative of the wider estate in shape, not necessarily in size.
- Genuinely used, so problems surface rather than staying theoretical.
- Small enough to reverse within a working day.
- Owned by a team with capacity to engage properly.
- Not the most critical system you run.
A pilot on something nobody depends on teaches nothing. A pilot on the payments system is not a pilot.
Run it in a separate account
A pilot should not be able to disturb the existing estate, and its cost should be plainly visible so the business case is based on observation rather than estimate. A dedicated account gives both, and makes cleanup trivial if the answer turns out to be no.
What to measure
| Dimension | Record |
|---|---|
| Effort | Person-days actually spent, versus estimate. |
| Performance | Latency and throughput compared with the current platform. |
| Cost | A full month of steady-state running, not a first-week figure. |
| Operations | What monitoring and runbooks had to change. |
| Surprises | Every unknown you hit. This is the real deliverable. |
| Rollback | Whether you could go back, and how long it took. |
Test the rollback for real
- Document the rollback procedure before you cut over.
- Define the criteria that would trigger it, in advance.
- Actually execute a rollback during the pilot.
- Record how long it took and what was awkward.
- Fix the awkward parts before the next wave.
Summary
Pick something real but reversible, run it in its own account, measure a full month of cost, rehearse the rollback, and treat the list of surprises as the main output.
