Platform migrations happen for sober reasons: a product version is reaching end of support, licensing has changed, the organisation has standardised elsewhere, or the estate has outgrown what it was built on. They go wrong for one reason: the bots are treated as code to be moved rather than as production services that must keep running every night while they are moved. The sequence below is built around that constraint.
1. Inventory what is actually running.
The documented estate and the real estate differ. Pull the list from the orchestrator or control room, not from the project tracker. For each bot record the schedule, the last successful run, the volumes, the systems touched, the credentials used, the owner, and whether anyone would notice if it stopped. Expect to find bots nobody owns, bots that have not run in a year, and bots that run but whose output nobody uses.
This inventory is the single most valuable artefact of the migration. A third of the estate often does not need to be migrated at all.
2. Triage into four buckets.
| Bucket | Criteria | Action |
|---|---|---|
| Retire | Not run in months, no owner, output unused | Decommission with the owner's sign-off, or a 30-day silence test |
| Convert | Simple, stable, well-structured, built to standards | Tool-assisted conversion where available, then full test |
| Rebuild | Complex, poorly structured, undocumented, or built on patterns the target does not support | Rebuild from the process, not from the old code |
| Redesign | The process has changed, or a better pattern now exists (API instead of UI, agent instead of rules) | Treat as a new automation with the old one as reference |
Vendors' conversion tools are useful for the convert bucket and misleading for the rest. A converted bot that compiles is not a converted bot that works. Budget full regression testing for every converted bot, and expect a share of them to move to rebuild once testing starts.
3. Set up the target properly before moving anything.
- Environments: development, test and production, with promotion between them through a release process.
- Standards: naming, project structure, logging, exception handling and the component library, adapted to the new platform.
- Credentials: a vault on the new platform, with the bot accounts recreated and the access re-approved. Do not copy passwords across.
- Machines and licences: sized for parallel running, which temporarily needs more than steady state.
- Monitoring: the new platform's alerts wired to the same support process before the first bot goes live on it.
4. Migrate in waves, by risk.
Start with a wave of low-risk, well-understood bots. The aim of wave one is to prove the pipeline: build, test, release, monitor, support. Fix the pipeline before wave two. Then move by business criticality, lowest first, keeping the most critical bots for last, when the team and the platform are proven.
Within a wave, group bots by the systems they touch. If five bots log into the same ERP, migrating them together means the ERP team is involved once, the shared component is built once, and the regression test data is prepared once.
5. Run in parallel, then cut over.
For any bot that touches a system of record, run the old and new versions in parallel for at least a full business cycle, with the new version in a non-writing mode or against a copy, and compare outputs item by item. Discrepancies are usually in edge-case handling and they are far cheaper to find here than after cutover.
Cut over one bot at a time, with the old bot disabled but not deleted, and a documented rollback: re-enable the old schedule, disable the new one. Keep the old bot in that state for an agreed period, typically a month, before decommissioning.
What to tell the sponsor.
A migration is a chance to come out with a smaller, cleaner, better-monitored estate than went in, and a team that knows every bot in it. Report it that way: bots retired, bots improved, straight-through rates before and after, support incidents before and after. The licence saving is usually the reason the migration was approved. The healthier estate is the reason it was worth doing.
Migrate the process, not the code. The code was only ever one answer to it.