A successful move finishes with verified business operations on the new foundation. The customer must know what moved, where data lives and who runs the service. Without that, changing the language retains the same contractor dependence. We treat migration as a managed service change with documented scope, acceptance and retirement of the old environment.
Define what is being migrated
Record pages, administration, APIs, schedules and external links. Decide whether each component moves, changes or is retired. Include invisible functions such as exports, emails, internal accounts and data imports. This turns “complete migration” into a verifiable specification and avoids maintaining features nobody uses or owns.
Confirm ownership of domains, infrastructure, source and external accounts. Resolve contractor-held resources before launch. Transfer production secrets through an agreed channel rather than putting them in documentation. The customer should know which temporary permissions were issued and when to revoke them after handover or staffing changes.
Define acceptance criteria
“Everything should work as before” is insufficient. Select scenarios: an enquiry reaches staff, an editor publishes, a customer sees only their records. Define success and failure. Pricing logic needs example calculations. Scenario-based acceptance exposes mismatches early and distinguishes defects from capabilities outside the agreed scope.
| Document or result | Why the customer needs it |
|---|---|
| Function inventory | Confirms migration scope |
| Data map | Explains storage and relationships |
| Acceptance scenarios | Demonstrate readiness |
| Cutover plan | Identifies actions and responsibility |
| Operating instructions | Enable ongoing maintenance |
Separate verification and production
Build the replacement separately. Use test or appropriately anonymised data when production records are unnecessary. Restrict administration and avoid exposing service interfaces without purpose. Environment settings belong in defined configuration. This supports repeatable deployment instead of one accidentally working test server with undocumented manual changes.
Checks follow risk: a catalogue and a financial debit need different attention. Verify critical chains and their final state, including external failures and retries. Trial data transfer and reconciliation are separate steps. Record actions, expected outcomes and observed results in a form the customer can understand.
Prepare cutover
Agree the change window, synchronisation and rollback trigger. Identify available decision-makers and temporary operation restrictions. Writes between export and cutover require explicit handling. DNS changes neither transfer orders nor prevent all access to the old platform. The plan must fit the actual service and traffic controls.
- Scope and owners → Acceptance criteria
- Acceptance criteria → Trial migration
- Trial migration → Reconciliation passed?
- Reconciliation passed? → Trial migration (No)
- Reconciliation passed? → Cutover (Yes)
- Cutover → Acceptance and PHP retirement
Rollback needs equal care. New records must survive it; temporarily pausing operations can be safer than routing back to an outdated database. Define acceptable errors and the decision owner. Complex services benefit from a rehearsal to measure real duration and correct instructions before production.
Who decides it is ready?
Each stage needs contractor and customer responsibility. Developers confirm technical checks while business representatives verify user outcomes. Accounting or warehouse staff participate in relevant scenarios. Appearance alone cannot establish readiness. Before cutover, specify who may stop launch and who receives blocking issues.
Classify feedback by impact. Incorrect amounts or access blocks launch; a newly requested animation can normally wait. Record decisions so acceptance does not depend on contradictory verbal expectations. Preserve any agreed exceptions where functions temporarily remain in the old environment.
The scope also establishes which information is authoritative during transition. A trial import is not permission for both environments to change the same records independently. Before the final synchronisation, the plan identifies where new operations are accepted and how they will be preserved. This is important even where the website itself looks unchanged, because an order or enquiry can arrive between two otherwise successful technical steps.
Instructions should be usable by someone who did not build the project. The customer needs the release procedure, configuration requirements and a tested recovery approach, without exposed credentials embedded in the documents. Practical repeatability is the evidence that ownership has transferred, rather than the mere presence of a repository link.
After handover, agreed maintenance and defect terms remain explicit. This avoids relying on verbal assumptions about how long the contractor will monitor the website or what counts as an additional request. Clear responsibility supports future changes without forcing the owner to repeat the original discovery process.
Finish the transition completely
After acceptance, check backup addresses, schedules and old panels. Removing a WordPress link does not disable the application. If PHP remains necessary, document the exception and its future. Complete retirement is established through the running environment. Retain old backups for an agreed period with controlled access so archives do not become uncontrolled sources of personal data or valid credentials.
Handover includes source, builds, configuration and backup instructions. Assign update responsibility and an issue contact, with defect correction and support terms documented. Another team should be able to take over without reconstructing every decision. A working site known only to one person is not a complete handover.
Send the project description and timing constraints. We prepare scope, sequence and a clear quote, including questions to resolve beforehand. Simple sites support short migrations; complex services need their own plans. In both cases, acceptance confirms functions, data, understandable operations and the absence of an unnoticed old dependency.
Sources
OWASP Top 10:2025. WordPress: security. Checked on 26 October 2026. Migration procedures, examples, prices and delivery conditions describe the project’s proposed service.
