A platform change may be justified: an integration may not work as expected, a required editor role may be missing, or the original architecture may be a poor fit. It is still a scope decision. The buyer approved a site with particular costs, access, and handover expectations; changing the platform can alter all of them.

Ask why the original plan no longer works

Request a short written explanation of the original assumption, what was discovered, and which requirement the current platform cannot meet. Ask what alternatives were considered, including staying on the original platform with a narrower feature. A preference for the provider’s familiar tool is not, by itself, a business requirement.

Separate a genuine technical blocker from a newly requested feature. If the signed scope promised a booking integration and the chosen platform cannot support it, the provider needs to explain the correction path. If the client added booking after signing, that is a new scope decision. The contract and evidence determine who bears any additional cost.

Recheck five consequences

  1. Total cost: new licenses, hosting, plugins, developer time, and ongoing subscription fees.
  2. Content and URLs: whether migration, redirects, or manual re-entry is required.
  3. Editing rights: who can update pages, what skills are needed, and whether export is possible.
  4. Integrations: forms, CRM, booking, payment, analytics, and authentication behavior.
  5. Schedule and QA: what must be rebuilt, retested, and approved before launch.

Ask for a side-by-side note showing the original plan and proposed plan. Where URLs will change, Google’s site-move guidance recommends mapping and testing redirects, internal links, and canonical URLs. A platform change can also affect domain and email settings, which should have a named technical owner.

Approve a revised milestone, not a verbal promise

The change order should name the new platform, revised deliverables, account ownership, handover format, pricing effect, dependencies, and test plan. It should also identify what happens to work already completed. Do not pay for duplicate effort without understanding why it is necessary under the signed agreement.

If the launch date must move, ask for intermediate reviewable deliverables rather than only a new final date. This gives both sides a way to identify whether the replacement plan is working. Keep the original and revised approvals together for later handover.

ARCHV’s website process says extra work should be agreed in writing and final scope follows the project brief. Its quote comparison can surface missing platform and handover terms before a project starts. A public client review about shifting dates during a platform change is an individual account, not a conclusion about that provider. The buyer safeguard is to reapprove the full operational impact.

If your business already has staff trained on the original platform, include retraining and editorial workflow in the decision. The new platform might solve a technical issue while making ordinary updates harder. Test one representative edit before accepting the switch. A platform decision is complete only when the business understands both launch behavior and day-to-day ownership.