A website migration can go off track before anyone copies a file. The kickoff arrives, but the agency still does not know who controls the domain, which forms feed other systems, whether paid plugins can move, or who will approve the new site.
A WordPress website migration form can surface those blockers while the project is still being scoped. The goal is not to collect every technical detail. It is to prepare a review packet that helps a WebMaster decide what must be confirmed, who owns each dependency, and whether the proposed timeline is credible.
Define the next migration decision
Start with the decision the intake should support. A discovery form for an early estimate needs different facts from a form used after the contract is signed.
- Estimate review: Is there enough information to define a likely range and name the biggest unknowns?
- Technical discovery: Which systems, owners, and access dependencies need a specialist before planning?
- Kickoff readiness: Are the people, assets, approvals, and environments available for work to begin?
Do not ask one form to make all three decisions. Pick the next gate, then collect the facts that can change its outcome.
Ask for facts that change scope
A long questionnaire can feel thorough while still missing the one dependency that stops the project. Build the form around scope-changing facts:
- the current platform, hosting arrangement, and number of sites;
- domain and DNS ownership, stated as an owner or provider rather than a password;
- forms, stores, memberships, learning systems, multilingual content, and other active features;
- systems that receive website data, such as email marketing, CRM, payment, or booking tools;
- content volume, media volume, redirects, and known SEO requirements;
- paid themes, plugins, fonts, or services whose licenses may not transfer;
- launch constraints, blackout dates, and the person authorized to approve the cutover.
The official WordPress migration guidance is a useful reminder that moving files and the database is only part of the work. Domain changes, server paths, configuration, and URLs can all affect the plan.
Use conditional questions
Do not make every prospect answer questions about e-commerce, memberships, or multilingual content. Ask a short screening question first, then reveal the relevant follow-up fields.
For example, a site that takes payments may need questions about gateways, subscriptions, tax, refunds, and order history. A brochure site does not. Conditional sections shorten the form for simple projects and preserve the detail needed for complex ones.
Keep labels concrete. “List active integrations and what each one does” is easier to review than “Describe your technology stack.” The W3C guidance on form instructions recommends explaining the expected input and any required format instead of making people guess.
Separate facts from assumptions
A migration brief should distinguish what the submitter stated from what the reviewer inferred. “Uses WooCommerce” is a reported fact. “Needs a complex commerce migration” is a conclusion that still needs technical review.
An Entry Summary can place the submitted facts in a consistent order. Keep the original entry available so staff can check dates, quantities, and product names before acting. If an answer is vague or contradictory, label it as unclear instead of smoothing it into certainty.
A clean brief should make the unknowns easier to see, not make them sound settled.
Flag blockers, not every empty field
An empty field is not automatically a problem. A missing DNS owner can block planning. A missing “How did you hear about us?” answer probably cannot.
Use a Missing Information Review against the next decision. Ask it to name only the gaps that prevent an estimate, technical review, or kickoff. Require a short reason for each flag so staff can reject weak suggestions.
If the same blocker appears repeatedly, fix the form. Add a clearer label, an example, or a conditional follow-up. The guide to improving form questions from repeated AI flags shows how review results can become a practical form backlog.
Route work without promising a schedule
Some migration inquiries need only a standard discovery call. Others need a hosting specialist, SEO review, commerce developer, or privacy lead before anyone quotes the work.
A Routing Recommendation can suggest the first owner from the submitted facts. Treat that result as a queue recommendation, not a staffing commitment. A person should confirm the owner, priority, and next contact before the client receives a promise.
The existing scope-review brief guide applies the same boundary to ongoing website changes: prepare the decision, preserve the request, and keep approval with the responsible person.
Never collect credentials in discovery
A migration form may need to know who controls the registrar, DNS, hosting, analytics, or email. It does not need the passwords, recovery codes, API keys, private keys, or full backup files.
- Ask for the system name and accountable owner.
- Record whether access is available, pending, or unknown.
- Move credential sharing to an approved secure channel after the project is authorized.
- Map only the fields needed for the AI review job.
Use the field-by-field method in Do not send every WordPress form field to AI. A useful discovery brief does not require copying the entire intake into a model.
Test five migration scenarios
Before using the workflow with clients, test it with a small set of synthetic or safely redacted examples:
- a simple brochure site with one contact form;
- a store with payment, tax, shipping, and order-history requirements;
- a site whose domain and hosting are controlled by different vendors;
- a rushed project with an immovable campaign date;
- an inquiry that does not contain enough evidence for a responsible estimate.
Write the expected blockers and first owner before running the actions. Then compare the generated brief with the original entry. Add a regression example whenever staff find an invented fact, hidden dependency, or bad routing suggestion.
Measure avoided follow-up
The useful outcome is not a longer discovery report. Track the work the form removes or exposes earlier:
- follow-up emails before a discovery call;
- calls rescheduled because the right owner was missing;
- estimates reopened after an integration or license surfaced;
- days between inquiry and a review-ready next step;
- brief corrections made after checking the original submission.
These measures show whether the intake is reducing uncertainty or just generating more text.
Start with one migration gate
Choose either estimate review, technical discovery, or kickoff readiness. Define the facts that gate that decision, add conditional questions, and test the brief with known scenarios. Expand only after the first reviewer can explain how the output changes the work.
Collect the facts that can change the next decision: current platform and hosting, domain ownership, active features and integrations, content and redirect needs, licenses, timing constraints, approval owners, and known access gaps. Do not collect passwords or secret keys.
No. AI can summarize submitted facts, flag missing blockers, and recommend a review queue. A qualified person should confirm technical feasibility, scope, timing, price, and commitments.
No. Ask which systems exist, who owns them, and whether access is available. Share credentials later through an approved secure channel after the project and recipients are authorized.
