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.
We migrate one slice of the project end to end. That slice can be one product (in a multi-product migration), one section of a large product, or one content type. The unit depends on how the project is shaped.
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
Picking the right slice matters more than anything else in the pilot. 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.
Plan less, ship one, then scale. The one slice you migrate is worth more than the plan it replaces.