- Page count
- How many pages actually move. Most documentation sets carry pages nobody has opened in a year, and the audit separates what migrates from what gets archived. The archived pile is the cheap part.
- Source systems
- One export from one platform is a straight run. Content split across a help centre, an internal wiki, a shared drive and a handful of README files means several extraction paths, several formats, and one merge that has to reconcile them.
- Rewrite vs convert
- Converting clean, structured content is mechanical work. Pages written in a WYSIWYG editor, with styling baked into the markup and no consistent heading levels, have to be rewritten rather than converted, and rewriting is priced as writing.
- Redirects
- If the current URLs are public and indexed, every one of them needs a mapped redirect and a link check before launch. If the docs are internal, or the domain is changing anyway, that work disappears from the quote.
- Authors to train
- Training two engineers who already work in Git is a short session. Onboarding a mixed group of writers, support leads and product managers who have never opened a pull request takes structured sessions and written guides they can use after handoff.
- Versioning
- Publishing a single current version is simpler than maintaining several released versions side by side, each with its own navigation, its own redirects and its own release workflow.
None of these is padding. Each one maps to hours inside a phase you can see in advance: the engagement process lists the phases in order and says who does what in each of them. If your setup has an awkward edge — a docs site that is half marketing pages, a translation workflow, an API reference generated from source — the FAQ covers the ones that come up most.