Migrating 30,000 pages of Confluence to Markdown sounds simple: pick the format, run a converter, deploy.
It rarely goes that way. Plans built on assumptions break the moment real content meets the new platform.
Thatâs why we donât quote large migrations up front. We pilot first.
Why a pilot first
Planning a full migration up front assumes you can predict what the work will look like. You canât. Not at this scale, not with content this varied.
A pilot surfaces what the plan canât see: the issues that only appear once real content meets the real platform. Some look like minor rendering bugs. Others reshape the whole approach.
So we migrate one slice end to end. That slice might be one product in a multi-product migration, one section of a large doc set, or a single content type. The shape of the project decides the unit.
Thatâs enough to know what the next slice will cost, what the rest will cost, and where the work is most likely to slip.
Picking the right pilot
The slice you pick decides whether the pilot is worth running. The temptation is to start with the easiest one: smallest content, simplest structure, friendliest team. Those pilots ship smoothly and teach you nothing about the rest. Pick something closer to the average instead.
Give the pilot a deadline too. Without one, it stops being a pilot and turns into the project itself, and you lose the reason you ran it in the first place.
And when leadership wants the full scope committed before any work starts, plan with the pilot in mind. Run one slice through the full workflow first, then narrow the estimate as the project takes shape.
Evidence over estimates
Most migration projects fail in scope-setting, not in execution. The pilot is how we set scope honestly. The estimate we give for the full project is the one we earned by doing part of it.
Ship one, then scale. Youâll learn more from one migrated slice than from any plan.