A managing partner at a 200-person consultancy approved £120,000 and five months for a CMS migration. The firm launched nine months later after spending £230,000.

The source describes this as a representative Distinction observation. The engagement, figures and permission need checking before publication. Its useful point survives that review: early migration estimates are often built from the visible website, while cost emerges from the content model, integrations, operating practices and decisions below it.

A credible budget is therefore a range tied to discovered complexity. Generic labels such as “simple”, “moderate” and “complex” can help a first conversation, although the source's £40,000 to £600,000-plus price bands and fixed durations are unsupported and will age. This article explains what to inspect so that the number presented to a board has a defensible basis.

Complexity comes from the estate, rather than the destination logo

Page count is one input. It does not show whether pages share a consistent model, contain unsupported components, depend on missing assets or need editorial decisions before they move.

Assess at least six dimensions:

Content structure. Count content types, fields, component variations, assets, languages and relationships. Sample actual pages at component level. A CMS definition shows the intended structure; long-lived sites often contain implementation drift.

Content treatment. Decide what will move unchanged, be rewritten, merged, archived or retained for legal reasons. Migration and content improvement are different workstreams that compete for the same editorial attention.

Integrations. Replace labels such as “Salesforce connection” with data flows, endpoints, volumes, mappings, authentication, error handling, ownership and test environments. Customisation in either system can make a standard connector irrelevant.

Custom behaviour. Identify calculators, search, personalisation, forms, gated content and workflows. Determine whether to reproduce, simplify or retire them.

Non-functional requirements. Accessibility, security, privacy, resilience, performance, records and regulatory needs influence architecture, assurance and approval.

Operating change. Editors, developers, service owners and approvers need roles, training and capacity. A platform migration that ignores how publishing works can reproduce the old constraints in a newer system.

These factors interact. A new content model changes migration mapping, templates, search and training. A CRM redesign changes forms, analytics and test data. The estimate should show dependencies rather than treating every line as independent.

Content work expands when decisions were deferred

Content migration is regularly underestimated because inventory is mistaken for readiness.

A page may contain obsolete claims, inaccessible files, broken media, duplicate material or layout encoded inside rich text. It may have no clear owner. Automation can move well-structured recurring content and identify anomalies. It cannot safely decide which legal statement remains current or which of two overlapping pages represents the firm's position.

Before estimating, take a risk-based sample across old, high-traffic, business-critical and unusual content. Record the percentage suitable for automated transformation, rules requiring review and exceptions likely to need manual treatment. Include quality assurance after import.

The source claims content usually takes two to three times the estimate and gives a 2,000-page case that grew from three weeks to nine. Those details need project evidence. The practical budgeting lesson is more precise: measure variation and decision demand before multiplying page count by a migration rate.

Integration estimates need production behaviour

An integration must do more than return the right field in development. It must operate at expected volume, degrade safely, surface failures and remain supportable when another supplier changes its service.

Discovery should establish:

  • Authoritative source for each data item
  • Direction, frequency and volume of movement
  • Mapping and transformation rules
  • Authentication, permissions and sensitive data
  • Rate limits, retries, queues and recovery
  • Monitoring, support and incident ownership
  • Test environment and representative test data

Price the build, assurance and continuing ownership. A short API specification is weak evidence if the client's implementation has years of custom fields and workflow.

Internal time controls elapsed time

The supplier estimate does not include all client cost. Content owners review decisions. Security and legal teams approve approaches. Technology staff provide access. Leaders resolve scope and risk. Editors test the new experience.

Create a client-side resource plan with named people, decision dates and cover. Estimate elapsed time from availability, rather than assuming every question receives an immediate answer.

This is especially important for partnership organisations where decisions require a group and meetings follow a fixed cadence. A two-day delay in a technical answer differs from waiting three weeks for the next committee.

Protect discovery, search and measurement

Migration changes URLs, templates, metadata and sometimes information architecture. Redirects, canonical treatment, structured data, analytics, consent and external links need explicit ownership.

The source applies unsupported percentages to SEO preservation and reports a 40% traffic loss. Remove those numbers unless project analytics and attribution can support them. The risk itself is established in the mechanics: an omitted redirect breaks a known route; missing measurement leaves the team unable to judge launch.

Build a URL inventory, map deliberate changes, test redirects and preserve an audit trail. Recreate analytics and important events before launch, then validate them in production. Search specialists should review material changes where organic discovery matters.

Launch begins an operating period

No realistic test plan reproduces every user, device, content exception and external dependency. Budget a defined post-launch period for monitoring, defect correction, content adjustment and learning.

The source recommends a universal 15% to 20% allowance. A risk-based plan is better. Estimate support from migration exceptions, system criticality, traffic patterns, service levels and the degree of change. Distinguish defect warranty from improvement so the client knows which budget owns each item.

Training also needs more than a launch walkthrough. Give editors task-based guidance, safe practice space and support during their first real publishing cycles. Track recurring questions as evidence that the platform or documentation needs improvement.

Give the board staged certainty

Boards may distrust a broad migration range because it appears imprecise. False precision transfers uncertainty into later change control.

Separate the decision:

  1. Approve bounded discovery and architecture work with defined outputs.
  2. Use those outputs to set the delivery range, assumptions and contingency.
  3. Identify go, change or stop criteria before the larger commitment.
  4. Release later phases against evidence and resolved dependencies.

The source suggests discovery is 8% to 15% of total cost and uses a £25,000 example. Those figures are not evidenced benchmarks. Scope discovery from the uncertainty it must resolve: content sample, integration investigation, user and editor needs, target architecture, delivery plan and cost model.

A board-ready budget should contain supplier cost, internal capacity, third parties, licences, assurance, content, training, launch support and contingency. Show which assumptions could move the range and when they will be tested.

A realistic estimate names what remains unknown

An estimate is more credible when it states exclusions and confidence. It should explain which content was sampled, which integrations were inspected, which owners have agreed the operating change and which current quotes underpin licences.

Underfunding does more than create an overrun. It encourages teams to cut migration QA, search protection, training and post-launch work when those are the controls that make the new platform usable.

If you want to establish the complexity of a specific estate, book a migration scoping conversation. Distinction should confirm the service's current duration and output rather than promise that a 90-minute meeting alone can calibrate a programme. Bring the content inventory, integration owners and uncomfortable unknowns; those are the inputs that make the eventual number useful.