Website migration cost depends on what is moving, what must be rebuilt, and what the provider is responsible for proving before launch. An unchanged WordPress site moving to another host is a different project from a CMS rebuild, a domain change, or an online store transfer with current orders and subscriptions.
The timeline depends on those same decisions, plus access, client reviews, third-party requirements, and the final cutover. A transfer tool might finish quickly while the project still needs content cleanup, testing, business approval, or reconciliation of new records.
For a useful budget, separate three amounts: the one-time work needed to complete the move, the ongoing services needed to operate the destination, and any temporary overlap or explicitly reserved allowance. For a useful schedule, separate hands-on work from waiting and approval time.
This guide explains the work that changes a migration quote, how to compare proposals fairly, and how to identify assumptions that can change the total. It includes an invented worked budget. Its figures are arithmetic examples, not US market averages or Web Expert Solutions prices.
Start with the migration you actually need
Before asking “How much?”, describe what will change and what must remain operational. A provider can give a more meaningful answer when the project has a defined source, destination, feature set, and acceptance standard.
The most useful distinction is between moving an existing application and rebuilding its capabilities on a different platform. A quote that says only “website migration” can hide that difference.
| Project type | What the quote needs to describe | What often changes the workload |
|---|---|---|
| Same-platform hosting move | Copy, compatibility, current data, routing, and verification | Application requirements, site size, access, live activity, and retained email |
| Domain or URL change | Relevant old-to-new destinations and a search transition | Address patterns, important content, existing redirects, and ongoing domain control |
| CMS or website-builder replacement | Content conversion, design implementation, and feature rebuilding | Export limits, content structures, forms, media, integrations, and editing requirements |
| Commerce or membership move | Data, business obligations, transactions, and operational acceptance | Products/options, customers, subscriptions, payments, permissions, and final synchronization |
| Migration combined with redesign | Separate transfer and redesign deliverables | New templates, revised content, approvals, accessibility, and scope changes |
More than one row can apply. A store might change hosts, platforms, and domains while also commissioning a new design. Each change needs an explicit place in the proposal, even if the supplier delivers everything through one project.
Write a short scope statement. For example: “Move the existing WordPress site to compatible hosting, retain its domain and URLs, keep the current email provider, and verify enquiry delivery.” That describes a substantially narrower job than “Rebuild the website in WordPress, replace its booking system, reorganize content, and change the domain.”
If the business is still deciding between those approaches, request a discovery stage or bounded feasibility review. That allows the team to resolve the expensive uncertainties before pretending the implementation is fully specified.
The guide to website migration types and process explains the operational branches. Here, the focus is how those branches affect the quote and calendar.
What advertised migration prices can—and cannot—tell you
Advertised offers show how much scope, eligibility, and the division of work matter. They shouldn’t be combined into a single price range as though every service includes the same deliverables.
| Advertised offer | What it usually describes | How to use it in a comparison |
|---|---|---|
| A host’s included or free migration | A transfer of a supported WordPress installation onto that host’s own service, subject to eligibility | Check eligibility and destination hosting costs; don’t assume it includes a different-platform rebuild |
| A self-service migration tool | A tool that copies a supported site at no extra charge, with the owner running and checking it | Compare its limitations and who fixes what it can’t move |
| A paid manual transfer | A provider-performed move for sites the tool doesn’t support | Ask which application work and testing are included; domain transfer is usually separate |
| A page-band or hourly price sheet | An estimate for a defined number of pages, with listed exclusions | Read the exclusions; the figure describes that scope, not your site |
A price sheet that quotes a few hours of work for a small site usually excludes custom design and content updates, and it may assume the requesting team does part of the work. Those details explain the number; removing them creates a misleading comparison.
Likewise, an included host migration can be valuable when it matches the job. It does not establish that the entire business transition costs nothing. Destination hosting, licenses, client review, feature changes, or tasks outside the offer may still have a cost.
Ask the provider to confirm the exact service rather than relying on a search-result price or an old promotional page. “From” pricing, account eligibility, supported source systems, and optional expedited work can change the meaning of an advertised offer.
Read the quote as a list of responsibilities
A useful quote explains the completed result, the assumptions behind it, and how acceptance will work. The work can be grouped into several stages even when the commercial proposal uses a fixed total.
Discovery and the source inventory
Discovery establishes what exists, what the business needs, and what the destination must support. It can include reviewing content types, public URLs, features, account ownership, service dependencies, current defects, and available exports.
The discovery task is smaller when the source is familiar, access is complete, and the desired outcome is narrow. It grows when several suppliers control different services or nobody knows which application creates an important business record.
Ask what discovery produces. Useful outputs include a scope statement, inventory, unresolved-question list, and a recommendation for the migration method. A discovery charge should correspond to defined work rather than an unexplained fee before an estimate appears.
Copying, importing, and content conversion
These tasks describe how information reaches the destination. They can involve copying files and a database, importing supported content, translating records between structures, or cleaning up a representative set before transferring the remainder.
The provider should state what the method covers and what it omits. A successful import message does not establish that images are owned by the destination, product options remain associated correctly, or editors can maintain the new content.
Price the reconciliation work as well as the initial transfer. Someone needs to check counts, identities, relationships, and meaningful samples. If that responsibility belongs to the client, the quote should say so plainly and the business should allow time for it.
Design and feature rebuilding
A platform change often requires rebuilding layouts or behavior that cannot be transferred directly. That can include page templates, reusable content structures, forms, bookings, account areas, or integrations.
Separate reproducing an existing approved design from developing a new one. “Make it look similar” can mean a practical theme adaptation or a detailed recreation with many special cases. Agree on examples, representative templates, and review rounds before treating either as a fixed deliverable.
For features, describe the complete task. “Contact form” should identify the fields, recipient, storage, connected actions, and acceptance check. A visible form and a working lead-delivery process are different levels of completion.
URL, search, and measurement work
If public addresses change, the quote should explain the content decisions, relevant replacements, implementation, and verification. Existing links and useful entry points need to be considered before the source is retired.
A same-URL hosting move has a different scope from a domain or path change. Google maintains separate guidance for hosting changes and moves with URL changes. A proposal should reflect the actual branch.
Specify whether search-facing review includes content output, canonical signals, indexing controls, internal links, sitemaps, and reporting access. The existing website migration SEO guide explains that acceptance work in depth.
Testing, cutover, and handover
Testing should cover the business tasks and representative page types agreed in the scope. Record whether the provider checks the destination only, supports a client review period, and repeats key checks on production after routing changes.
Cutover includes the final-data decision and the public switch. A site that accepts current orders or submissions may need a different process from a static information site. Ask who reconciles activity that occurs after the first copy.
Handover should establish ownership, access, backups, retained dependencies, and ongoing responsibilities. If the quote ends at “files transferred,” the business still needs to identify who handles approval and operations afterward.
Page count matters less than content patterns and exceptions
Page count can be a useful starting input, but it is a weak description of implementation effort by itself. Many pages sharing a well-understood structure can be easier to migrate than a small site with several unusual features.
Identify the number of content types and representative templates. A page, article, product, staff profile, event, or location may need its own destination structure. Then identify the exceptions inside each type.
A resource library might contain ordinary articles, embedded media, complex tables, and gated downloads. Transferring the text is only one part of preserving that library. The quote should explain how those patterns will be represented and checked.
Content quality affects effort too. Inconsistent headings, broken embeds, duplicate records, and missing source files can require cleanup. Decide whether the migration preserves the current material, fixes defined defects, or includes a larger editorial rewrite.
Media needs particular attention. An imported page can display an image that still loads from the source platform. Confirm whether the work includes moving required media into an appropriate owned destination and checking important documents.
Ask the supplier to price a representative sample before extrapolating across a large archive. A sample can reveal whether most records follow a repeatable pattern or whether manual exceptions dominate the work.
Where per-page pricing is used, define a page and its included treatment. Does the unit include import, layout cleanup, metadata, media, links, review, and corrections? Two proposals using the same unit label may be pricing different results.
Platform limitations can turn a transfer into a rebuild
The source platform controls what information can be exported and how much of its application behavior travels with it. The destination then determines how that material can be represented and maintained.
Wix explains that its complete site depends on Wix’s hosting and technology. A move away should therefore be scoped around the content and features that need rebuilding or reconfiguration, rather than assuming a conventional file copy.
Squarespace documents the scope of its content export. Review those limits for the actual site instead of treating an XML file as proof that the complete application has been preserved.
WordPress.com also distinguishes full-site migration and content-only importing. Its methods belong to that specific destination service, but the distinction illustrates a wider scoping question: are you moving an application, importing selected content, or rebuilding an experience?
For a WordPress destination, agree how the business will edit ordinary content afterward. A low initial price can conceal a destination where routine updates require custom work. Conversely, a carefully selected reusable structure can reduce both implementation effort and later maintenance.
Use the platform-specific guides when comparing a Wix-to-WordPress project or a Squarespace-to-WordPress project. Their limits are part of the budget, not details to discover after approving it.
Commerce, memberships, and bookings add operational work
An active application has obligations that continue while the destination is prepared. The quote needs to account for them separately from the visible pages.
For a store, inventory products, variants, customer records, current orders, stock behavior, payment relationships, and any subscriptions. Confirm which system holds the authoritative record and which information can be transferred through the chosen method.
A Shopify product export is a defined data operation. It should not be treated as a complete migration of every store feature, historical obligation, or third-party application. Review the full route in the Shopify-to-WooCommerce guide.
Membership and booking projects need comparable care. Existing access rights, appointments, renewal behavior, customer communications, and external records can matter more than the number of public pages.
Ask how testing will represent these tasks. A successful checkout preview is useful, but it does not by itself verify how staff manage the resulting order or how external payment updates are reconciled.
The final-data method also affects the quote. A first copy can become stale while customers continue transacting. A supported synchronization, a controlled change freeze, or another reviewed method needs an owner and acceptance checks.
Keep the implementation estimate separate from promises about business interruption. The team should explain which functions can continue, what may pause, and how current records are protected. A provider cannot answer those questions reliably from a homepage URL alone.
Budget for integrations, email, and infrastructure separately
The website may connect to systems that are owned and billed elsewhere. A new page design can leave those relationships unchanged, or a platform move can require them to be rebuilt. The quote should identify which applies.
For each important connection, record the service owner, purpose, destination requirements, and test. Examples include payment processing, customer records, accounting exports, appointment services, delivery systems, search providers, and website email.
Credentials and documentation can affect the effort. An integration with an available owner and a supported test environment is easier to investigate than one maintained by an unavailable contractor with no clear account access. That is a planning dependency to resolve, not a reason to publish secrets in the project brief.
Staff email is a separate decision
Changing the web host does not necessarily move staff mailboxes. If email stays where it is, preserve its dependencies. If it moves, include mailbox setup, history, aliases, device changes, and verification in the scope.
A quote can include DNS configuration while excluding email migration. Ask exactly what that means. Retaining a mail provider and transferring years of messages into a new service involve different tasks.
Website-generated messages also need their own review. A working staff inbox does not prove the destination’s contact forms, password resets, or order notifications can send correctly. Include the relevant paths in acceptance.
The guide to changing hosting without losing business email explains these dependencies. Use that separation when checking whether two migration offers cover the same work.
Hosting, domains, and DNS do not share one renewal date
List the current and proposed services with billing periods, owners, and cancellation conditions. Domain registration, DNS, hosting, mail, software licenses, and support can be spread across several accounts.
Some overlap can be deliberate. Keeping the source available during testing or observation can cost money, but it may be necessary to retain files, email, routing, or recovery options. Define what the overlap protects and when it can end.
DNS timing needs a realistic explanation. A record’s time to live affects caching, but lowering it does not erase answers already cached. Cloudflare’s TTL documentation explains the mechanism. Do not build a whole project promise around an assumed instant routing change.
For a domain change, ongoing control of the old name and required redirects can remain part of the operating cost. The new website being visible does not automatically make every old account safe to cancel.
Existing defects and technical debt can change the scope
A migration can expose problems that existed before the move: unsupported components, damaged content, inconsistent data, insecure access, unreliable forms, or an integration whose behavior was never documented.
Record those findings rather than quietly bundling every repair into an undefined migration fee. The business can choose to fix an issue, accept a limitation, or change the destination approach. Each choice has consequences for cost and acceptance.
Compatibility work needs particular attention on a hosting transfer. A newer environment may reveal application assumptions that the old host tolerated. Ask whether compatibility review and defined corrections are included, and what happens if a major custom component needs redevelopment.
An obviously compromised or unreliable source can also change the preparation needed. Copying the current state may preserve the problem. A provider should explain the required investigation without claiming that a migration automatically constitutes a security cleanup.
Separate a reasonable discovery assumption from a known defect. “We will inspect the representative import before finalizing the remaining conversion estimate” is understandable. “Any problem we find costs extra” is too vague to help a buyer assess the commitment.
Use the WordPress migration problems guide for the functional symptoms themselves. In the quote, the important question is who investigates, which corrections are included, and how additional work is approved.
Compare fixed fees, hourly work, and phased estimates
The pricing model should fit how well the project is understood. A model label alone does not establish that an offer is fair, complete, or predictable.
Fixed fee
A fixed fee can be useful when the source, destination, included features, and acceptance are defined. The proposal should state the assumptions that support that amount and the changes that would require a revised quote.
Look for boundaries around content volume, representative templates, integrations, review rounds, and current-data work. A clear exclusion can help a buyer plan; an ambiguous inclusion can create disagreement later.
Ask whether provider corrections to an agreed deliverable are treated differently from a new client request. A form that fails its agreed recipient check is not the same situation as adding a previously unrequested sales workflow.
Hourly or time-based work
Hourly work can suit investigation or a project whose exceptions are difficult to predict. Ask for an initial estimate, reporting method, review points, and the approval required before additional work proceeds.
The rate and the number of hours belong together. A lower rate does not establish a lower completed cost when methods, coverage, and expected effort differ. Likewise, a higher rate does not prove a better result.
Agree on what records the provider will supply: work completed, time used, unresolved dependencies, and the next estimate. The business needs enough visibility to make decisions before the budget is exhausted.
Discovery followed by implementation
A phased approach can resolve important unknowns before the larger commitment. A useful discovery phase might produce a sample transfer, scope, destination plan, and implementation estimate.
Define what the business receives even if it does not continue with the same supplier. Also distinguish an exploratory result from an implementation guarantee. A successful sample supports an estimate, but the remaining inventory still needs review for exceptions.
Where a known part can be priced immediately, a provider can separate it from the uncertain part. The aim is to make uncertainty visible and manageable, rather than forcing every task into the same commercial arrangement.
A worked website migration budget
The following budget is invented solely to demonstrate the calculation. All dollar amounts are assumed US dollars. The hours, $85 hourly rate, service charges, and reserve are not market averages, a customer case, or a Web Expert Solutions quotation.
Assume a small business project with a defined content set, limited rebuilding, one important form, approved URL decisions, and a documented launch review. Major redesign, complex commerce, mailbox migration, and unexpected custom development are excluded from this example.
Calculate the one-time implementation work
| Illustrative work item | Assumed hours | Assumed rate | Illustrative amount |
|---|---|---|---|
| Discovery and access review | 3 | $85/hour | $255 |
| Inventory and URL decisions | 5 | $85/hour | $425 |
| Transfer and bounded rebuilding | 8 | $85/hour | $680 |
| Content and workflow testing | 6 | $85/hour | $510 |
| Final synchronization and cutover | 3 | $85/hour | $255 |
| Documentation and handover | 2 | $85/hour | $170 |
| Illustrative labor total | 27 | $2,295 |
Add an assumed $80 one-time tool charge and $75 for temporarily retaining the old service. The example’s one-time total becomes $2,450: $2,295 + $80 + $75.
This calculation is useful because the assumptions are visible. If the form needs a new integration or the content requires extensive cleanup, the appropriate response is to revise the affected scope and amount. The original total should not be stretched to imply that those tasks were included.
The labor split is not a recommended ratio. Another real project could require little rebuilding and substantial testing, or extensive conversion before any meaningful review is possible. Use the table structure with an actual supplier’s scope and figures.
Add the ongoing services without double-counting them
Assume, only for this example, that destination hosting costs $30 per month and a required software license costs $120 per year. Twelve months of hosting is $360, so the modeled annual operating amount is $480.
The example’s implementation plus twelve months of those two ongoing services is $2,930: $2,450 + $480. Taxes, transaction-based charges, maintenance, and other services are excluded from this calculation. They must be added if they apply to the real scope.
Check the time boundaries. The $75 overlap is a separate assumed temporary item in this model. If a real quote already includes the same hosting period or tool license elsewhere, do not add it twice. Specify when each recurring charge begins and whether the stated price is introductory or a confirmed renewal amount.
For later years, update the model with the actual renewal terms and services then required. Holding the example’s inputs constant would produce $480 for those two annual items, but that is an arithmetic assumption, not a prediction that a provider’s prices or the business’s needs will stay unchanged.
Keep a reserve separate from the committed quote
Suppose the business sets aside an additional $250 for work it has not yet authorized. The illustrative budget envelope would be $3,180, but the $250 is not automatically a provider charge or a task already purchased.
Record what can trigger use of that reserve and who approves it. If the project does not need the additional work, the reserve remains uncommitted. If a discovery finding is already known, price it as defined work rather than hiding it inside a vague contingency.
This distinction prevents three different amounts from becoming confused: the agreed implementation fee, expected operating charges, and the business’s optional allowance for an unresolved change.
Read the first-year total and the renewal-year total separately
The migration fee is only part of the cost of the destination arrangement. Make a short service register so the business understands what it will continue paying for and who controls each account.
Include destination hosting, domain registration, mail, required themes or plugins, external applications, backup/storage services, and any ongoing support the business chooses. A project may need only some of these; list the actual dependencies instead of adding a generic bundle to every estimate.
Distinguish existing costs from new incremental costs. If the business retains its current mail service at the same charge, that is still an operating expense, but it is not automatically a cost created by the migration. If the old host bundled email and the new arrangement separates it, the apparent hosting saving needs the new mail cost alongside it.
Check introductory terms and renewal periods directly. A monthly display price may involve an upfront commitment, while an annual license can be needed before launch. Compare actual payment timing as well as the modeled yearly total.
Ask which licenses belong to the business and which depend on the supplier’s continuing arrangement. Vendor terms differ, so confirm them rather than assuming that every component transfers when a development relationship ends.
Support also needs a defined role. Correcting an agreed migration defect, updating software six months later, and building a new feature are different services. Price and document the ones the business wants.
A destination that costs more to operate can still be appropriate if it solves the intended problem and the business can maintain it. A lower subscription total can also be attractive when the project retains the needed capabilities. The comparison should show the actual service tradeoffs, not just a smaller line labeled hosting.
Compare proposals against one common result
Two migration proposals can differ because the suppliers use different methods, because one includes more work, or because their estimates and rates differ. Identify which explanation applies before deciding that one price is excessive or another is unusually good value.
Create a common brief and ask each provider to mark the requested items as included, excluded, client-supplied, or unresolved. Include content handling, features, URL work, current data, testing, cutover, handover, and support.
Here is an illustrative comparison. The offer labels and amounts are fictional and do not represent named suppliers:
| Item | Hypothetical Offer A: $1,200 | Hypothetical Offer B: $2,450 |
|---|---|---|
| Basic transfer | Included | Included |
| Defined content cleanup | Client responsibility | Bounded sample-based scope included |
| Form/integration acceptance | Basic page check only | Agreed end-to-end check included |
| URL decisions and testing | Not priced | Defined scope included |
| Final changes after first copy | To be agreed | Stated synchronization method |
| Handover and exclusions | Needs clarification | Documented in scope |
The table does not prove which supplier costs less for a completed equivalent project. Several items in Offer A remain unpriced or assigned to the client. They are not zero-cost simply because the proposal leaves them blank.
Ask for the missing amounts or decide explicitly that the business will perform the work. Include the capacity and calendar needed for client-supplied tasks, even where no external invoice is involved.
Also compare the evidence promised. A statement that every URL will be checked is different from a limited sample, but the appropriate coverage depends on the site and implementation. Have the provider describe the source set, important exceptions, and review method rather than relying on an impressive-sounding percentage.
The fairest comparison is the price of an agreed result with known limitations. It should be possible to explain the difference without guessing what either provider meant by migration.
Include the work your own team must supply
Client responsibility can reduce a supplier’s fee while increasing the business’s own workload. Make that tradeoff visible before selecting the offer.
| Client-supplied work | Capacity to confirm | Dependency it can create |
|---|---|---|
| Content cleanup and approval | Someone who understands the material and can edit it | Implementation waits for an approved source set |
| Feature and business-rule decisions | An authorized operational owner | Testing cannot establish the intended result |
| Destination review | Available reviewers with a coordinated response | Corrections and launch scheduling remain blocked |
| Post-move administration | Someone able to manage the chosen tools | Routine updates depend on additional assistance |
These tasks need more than an assurance that the client will help. Identify the people, the expected outputs, and when they can contribute. A business with one busy owner may choose a different division of work from an organization with a dedicated content team.
Separate external cash payments from internal capacity. Existing staff time is not automatically an additional invoice, and adding full salaries to a small migration estimate can distort the comparison. It is still a real scheduling commitment that can displace other work.
If the business models an internal cost, state the chosen method and keep it separate from the provider’s quote. Do not mix that internal model into a claim about market pricing.
Also agree what happens when a client-supplied item is late or incomplete. The provider may be able to perform the task under an approved scope change, or the milestone may need to move. Resolve the choice while it is manageable instead of discovering at launch that each side expected the other to finish it.
What determines the website migration timeline?
A migration schedule should describe when the project can be accepted, not merely how long a copying tool runs. The calendar includes preparation, implementation, reviews, corrections, final data, launch, and any agreed observation or handover period.
Ask when the proposed clock starts. Is it the date of payment, the kickoff meeting, receipt of complete access, approval of the design, or acceptance of the content inventory? The same stated duration can describe different commitments depending on that starting condition.
The end needs a definition too. “Migration completed” might mean a destination copy is ready for review, public routing has changed, business acceptance has passed, or post-launch support has ended. Those are useful milestones, but they are not the same event.
Preparation and access
The first stage can include account recovery, source review, backups, destination setup, content inventory, and the decisions required to proceed. Waiting for domain or platform access can hold up work that appears simple on the surface.
Identify those dependencies before booking a public launch. A provider can sometimes start content planning while access is resolved, but it cannot verify every source capability from a public preview.
Client-supplied information belongs in the preparation plan. Specify who provides content decisions, integration details, approved recipients, product rules, and any brand assets the destination needs. A task should have an owner rather than sit in a general list called things to send.
Sample transfer and implementation
A representative sample helps establish how the destination handles the difficult content and feature cases. The schedule should allow the team to inspect that result and adjust the method before repeating it across the full site.
The remaining build duration depends on repeatable work and exceptions. Reusing an approved template can make later pages more predictable. Discovering several incompatible custom structures can require another decision before implementation continues.
Ask how progress will be demonstrated. A working sample, completed content family, or verified integration is more useful than a percentage that does not identify what is ready for review.
Client review and revisions
Review is a project activity with its own participants and dependencies. Set expectations for the business’s response time and how feedback will be consolidated.
A review round should have a practical meaning. It might cover a defined set of pages and features, with one coordinated response from the client. If different stakeholders repeatedly add contradictory requests, the team can lose time reconciling decisions before making any technical change.
Separate correction from expansion. A page missing approved content needs a correction. A request to redesign the entire navigation after the agreed structure was implemented changes the work. The schedule should show how each is handled without treating every comment as a new project or every new requirement as a free correction.
Availability matters as much as the number of reviewers. If the person who can approve payments, product rules, or the domain change is absent, other completed tasks may wait. Name a substitute decision owner where the business requires continuity.
Final synchronization and launch readiness
The destination can be ready visually while its current data is not ready for launch. Establish how content, enquiries, orders, or other changes made during preparation will be reconciled.
A longer review period can create additional final-data work. That does not automatically justify an unexpected invoice, but the possibility should be an explicit assumption in the quote. State whether one final synchronization is included and what changes would require another.
Choose the public switch when the required reviewers and operators are available. An advertised launch time is not useful if nobody can verify the live form recipient, approve a business interruption, or resolve an infrastructure problem.
Keep the business’s busy periods in view. A quiet publishing window and a busy store campaign have different operating constraints. The schedule should explain the chosen window without claiming that all customer activity will be unaffected.
Post-launch checks and closure
The public switch should be followed by agreed production checks. Record who confirms important content, URLs, business journeys, reporting access, and current records.
An observation period can be part of the service, but it needs defined tasks. Watching for known release issues, reviewing available signals, and investigating a reproducible defect are specific responsibilities. A vague promise to monitor everything indefinitely is not a useful completion standard.
The project’s closure should identify retained source services, outstanding exceptions, access ownership, backup responsibility, and ongoing support. The business should understand which activities continue after the implementation fee ends.
Separate labor, elapsed working days, and public interruption
Three time measures often become confused in migration discussions.
Labor is the hands-on effort assigned to tasks. It may be estimated in hours or another agreed unit. It is the quantity that can be multiplied by a rate in a time-based model.
Elapsed project time is the calendar occupied by the sequence of work, waiting, dependencies, and approvals. A project containing a modest number of labor hours can still span several working days if reviews or provider scheduling occur between tasks.
Public interruption describes when a visitor cannot perform a particular task. A site can remain available while staging is prepared, yet an active checkout or editing workflow may need a controlled pause during the final-data transition.
Ask the provider to state all three where they matter. “The migration takes a few hours” is incomplete if it describes only a copy operation and the business still needs several review stages. “The project takes several weeks” does not establish that the public website will be offline for that period.
Also define the time zone and working calendar. An owner’s Monday morning can fall outside the implementer’s agreed support window. Public holidays, weekends, provider availability, and reviewer schedules need to be reflected in the actual commitment.
Some providers distinguish scheduled and expedited work, each with its own requirements. Treat that as a provider-specific arrangement, not an industry-wide timeline.
An expedited option can affect queue priority or staffing availability. It cannot make missing content decisions or unresolved account ownership disappear. Confirm which part of the schedule the additional charge changes.
An illustrative migration schedule
This is a separate scheduling illustration, not a typical duration or a conversion of the worked budget’s 27 labor hours. Assume the stages occur sequentially on an agreed working-day calendar, access is available, and the scope remains stable.
| Illustrative stage | Assumed elapsed working days | What allows the next stage to begin |
|---|---|---|
| Discovery and scope approval | 2 | The required decisions and access are available |
| Destination preparation and bounded implementation | 4 | The agreed sample and content set are ready for review |
| Client review | 3 | One authorized response is returned |
| Corrections and acceptance testing | 2 | Required checks pass or exceptions are accepted |
| Final synchronization and launch checks | 1 | Current data and public operation are verified |
| Illustrative sequential total | 12 |
The total is twelve elapsed working days because 2 + 4 + 3 + 2 + 1 = 12. The stage durations are scheduling windows, not a statement that each person bills eight hours for every day in the table.
If client review expands from three working days to six, the same simple model becomes fifteen working days. That additional waiting does not automatically create three full days of billable labor. It can, however, move a reserved launch window or require a new final-data check. The quote should explain those consequences rather than assuming them.
If content approval takes place in parallel with another task, some elapsed time may shorten. Do not subtract overlapping durations blindly. The next stage can start only when all of its required inputs are ready.
This is the critical-dependency question: which unfinished task currently determines the earliest safe next milestone? A team can have spare development capacity while waiting for the only person who can approve the product data or regain domain access.
Use the model to ask better questions, not to impose the sample duration on another provider. A real schedule needs the actual method, scope, capacity, and dependencies for the particular site.
Why one late decision can change both cost and time
Some changes are cheap when made early and expensive after implementation. A content model agreed before an import can guide the whole transfer. Changing it after all records have been converted may require rework and another review.
A URL structure has similar dependencies. Reorganizing categories can affect navigation, content relationships, redirects, and tests. It should be considered as one connected change rather than a small edit to an address field.
Track approvals that define later work. Useful examples include the destination platform, content types, template sample, integration approach, URL policy, and final-data method. Record what was approved and which assumptions remain open.
When a change is proposed, ask the implementer to describe its affected work, additional cost if any, revised milestone, and acceptance changes. That creates a concrete decision for the business instead of an argument about whether the request sounds minor.
There is no need to freeze every preference at kickoff. A project can reserve a defined review process and allowance for expected refinement. The important distinction is whether the estimate already covers that refinement and what happens when the work expands beyond it.
Keep change decisions visible to the whole team. A new feature agreed privately with one person can otherwise reach testing as a surprise to another. Shared decisions reduce avoidable rework without requiring a large bureaucracy for a small site.
Three project scopes that produce different estimates
The following scenarios are invented. They illustrate the questions that shape a quote and schedule, not completed client work, standard prices, or guaranteed durations.
A business changes hosts and retains its current site
A service business has a working WordPress site, ordinary content, one enquiry form, and staff email managed separately. It wants compatible hosting and has no planned design, domain, or URL changes.
The provider reviews access, application requirements, current records, and the retained email arrangement. The quote includes a destination copy, representative testing, a defined final-data step, the routing change, and handover. It excludes a redesign and mailbox transfer.
The main uncertainties are whether the existing application runs correctly at the destination and whether the form’s complete delivery path works. A technical problem found during the sample needs a recorded decision about included corrections or additional work.
The schedule can keep the old site available during preparation, but the launch still requires the right people to verify the public result. Keeping the scope narrow makes the estimate more understandable; it does not remove the need for acceptance.
This business should first compare the provider’s included transfer service with the full result it needs. The detailed WordPress hosting transfer guide can help identify tasks the offer may leave to the owner.
A company moves a website-builder site into WordPress
Another business wants a more manageable content library and a different editing structure. The source contains articles, galleries, forms, documents, and an embedded booking service.
The estimate separates content transfer, template implementation, media cleanup, form rebuilding, and the treatment of the booking connection. It does not assume every source feature can be exported or that every embedded service must be replaced.
A representative sample is especially useful. It shows whether the content model works, how much cleanup is required, and whether the owner can maintain the result. The full implementation estimate should reflect those findings.
Client review can be a significant schedule dependency because the business must approve the structure and content, not just a new homepage. The proposal should identify review rounds and how further changes affect price and timing.
This is a rebuild with migration tasks. Comparing it directly with a host’s file-transfer offer would hide most of the required work. An appropriate quote explains the completed destination and the features it will support.
An active store changes platform and public addresses
A retailer wants a new commerce platform and revised URLs while continuing to accept orders. It also has current refunds, customer accounts, and subscription obligations in connected systems.
The quote begins with the source/destination data route and the treatment of those obligations. Product volume matters, but so do variations, relationships, permissions, transaction behavior, and the supported final-data method.
The estimate includes appropriate tests for the merchant’s actual workflows and the work needed to approve the destination. It also identifies what the merchant or another specialist must supply, such as account access, configuration decisions, and approvals for business rules.
The launch window depends on controlled live processing and reconciliation. Keeping both copies available does not mean they should independently accept the same live work. The operator needs a clear source of authority and a recovery approach that preserves new information.
The schedule and price therefore reflect a business-system transition, not simply a product-file import. The merchant should ask for a route-specific scope and evidence before relying on a fixed total or a short public-switch estimate.
Reduce cost by simplifying decisions and scope
The most useful savings often come from removing work that the business does not need or making necessary work more repeatable. Review those opportunities before cutting verification or leaving essential tasks unassigned.
Keep suitable public URLs where the destination supports them. That can reduce address-change work, although the site still needs content and application checks. A new design does not require every path to change.
Reuse approved templates instead of creating a unique layout for every ordinary page. Identify the content types that truly need different treatment and choose representative examples early. A clear content model supports both the migration and future editing.
Decide which old material still has a useful role. Removing genuinely obsolete content can reduce conversion work, but preserve information that customers, staff, links, or ongoing obligations still need. A low recent traffic count is not enough by itself to settle that decision.
Prepare source material in a form the provider can use. Supply approved content, actual source files, known feature requirements, and consolidated feedback. Check with the implementer before reorganizing exports manually; a well-intentioned edit can damage record relationships or make a supported import harder.
Retain suitable external services where they still meet the requirement. An existing booking or mail provider does not have to be replaced solely because the website platform changes. Confirm the destination connection and ongoing charges before making that choice.
Consider phased improvements. A business may be able to complete the necessary move and defer an optional design feature. Record the boundary so that the later phase does not become an unfinished prerequisite for a usable launch.
Ask the provider which proposed simplification actually changes the estimate. Some tasks share a setup cost, so removing one page may have little effect while removing a custom integration changes the project substantially. Savings should follow the real work rather than a cosmetic reduction in the brief.
Track the estimate while the project is underway
Keep an agreed view of completed work, remaining work, approved changes, and unresolved decisions. That record helps the owner understand whether the original estimate still describes the project.
For a fixed fee, focus on deliverables, assumptions, acceptance, and approved scope changes. For hourly work, also review time used and the current estimate to complete. A progress update should identify what is ready, what is blocked, and what decision is needed next.
Avoid mixing money already committed with an unapproved allowance. If a new feature is proposed, show its cost and schedule effect separately until the business authorizes it. An available reserve does not mean every possible change should be purchased.
Review recurring commitments when they are selected, not only at handover. A plugin or external service introduced during implementation can create a continuing bill, renewal dependency, or ownership decision.
If the estimate changes materially, ask for the reason at the level of actual work. A new data requirement, a revised design, and a failed access assumption have different implications. The update should explain the revised scope and next milestone rather than simply report that the project is taking longer.
Maintain proportionate documentation. A small project can use a short shared record; a larger system may need more formal coordination. The goal is for the business and provider to have the same understanding of the remaining commitment.
Define support, defect correction, and completion
The migration’s end should establish a stable operating arrangement and make remaining responsibilities visible. Ask what the quoted post-launch support covers and how the business reports an issue.
Distinguish correcting a failure against agreed acceptance from maintaining the site over time. An agreed form that does not reach its intended recipient is different from a request for a new form field or an unrelated future plugin update.
Define the support period, contact route, expected response arrangement, and exclusions in the actual proposal. Do not assume that a one-time migration fee purchases indefinite availability, or that every future problem will necessarily be a migration defect.
Acceptance should identify important tested content and workflows, current-data reconciliation, agreed URL behavior, access, backup responsibility, and known exceptions. The business should be able to understand what it is approving.
Retiring the source is a separate decision. Confirm whether it still holds files, mail, records, routing, or recovery material. A source service that must remain active should have an owner and a budget line rather than becoming a forgotten invoice.
If the business needs continuing assistance, an appropriately scoped ongoing website support service can be assessed separately. Choose the actual maintenance and support responsibilities the site requires instead of assuming migration and ongoing care are the same purchase.
What to send when requesting a migration quote
A short, specific brief is more useful than a large collection of unrelated documents. Give the provider enough information to identify the migration branch, important constraints, and representative exceptions.
Include the current public website, source platform, proposed destination, and the reason for moving. State whether the design, domain, page paths, or content structure will change. If the destination is undecided, say which requirements the provider should help evaluate.
Describe the content and features at a practical level. Approximate volume can help, but also identify products, custom collections, bookings, memberships, documents, forms, languages, and integrations. Mention ongoing transactions or records that must remain current.
Provide the desired deadline and its reason. Separate a fixed external commitment from a preferred date, and explain when reviewers can participate. Identify one person who can consolidate decisions and approve the launch.
List known problems and access gaps. The provider can then propose the right discovery or compatibility review instead of discovering late that a key account is unavailable or the source already has a serious defect.
Share access through the provider’s appropriate controlled process when needed. A public enquiry form should not contain passwords, private keys, customer exports, or payment details. The first request can describe what access is available without disclosing the credentials themselves.
Ask for the output you want: a written scope, exclusions, price basis, recurring commitments, schedule assumptions, acceptance checks, and handover. These are the ingredients of a usable comparison.
A migration quote and timeline checklist
Use the checklist before approving a proposal. An unresolved item should remain a visible question or assumption rather than being treated as included work.
Scope and price
- The source, destination, and changes to platform, domain, paths, design, and features are clear.
- Content types and exceptions are described alongside approximate volume, rather than page count being the only input.
- Transfer, rebuilding, cleanup, URL work, current data, testing, and handover have defined owners.
- Exclusions, client-supplied tasks, third-party charges, and ongoing services are visible.
- The fixed-fee, hourly, or phased basis explains what happens when an assumption changes.
- Illustrative amounts, provisional allowances, and approved prices are clearly distinguished.
Schedule and readiness
- The start condition and each completion milestone are defined.
- Required access, content decisions, representative samples, and reviewer availability have owners.
- Review rounds and response expectations are included in the calendar.
- Labor estimates are separate from elapsed time and any interruption to a public function.
- The final-data method, launch window, production checks, and recovery decision are described.
- A delay or change has an agreed process for reviewing its price and calendar effect.
Acceptance and continuing costs
- Important content, workflows, and current records will be verified through agreed checks.
- Source-service retention and cancellation conditions are documented.
- Renewal timing, account ownership, license dependencies, and ongoing support are understood.
- The handover names owners for access, backups, monitoring, remaining issues, and future maintenance.
Buy a defined result and an understandable schedule
A migration quote is useful when it connects the price to a completed, verifiable result. Start with the actual type of move, identify the work that surrounds the transfer, and compare proposals against the same scope.
Keep implementation, recurring services, temporary retention, and optional reserves separate. For the timeline, ask what work is hands-on, what depends on another decision, and which checks allow the public switch to proceed.
For a written scope, Web Expert Solutions’ website migration service can review the current site, intended destination, critical features, and planned address changes. A clear description of those requirements supports a more meaningful quote and schedule before implementation begins.
Frequently asked questions
1. How much does website migration cost?
The cost depends on the actual work: an eligible host transfer, a CMS rebuild, a domain change, and a commerce transition have different scopes. Some hosts include particular WordPress migrations, while other projects require separately priced discovery, rebuilding, data work, and testing. Ask for the result and exclusions behind the number. The worked budget in this guide is invented, not a market estimate.
2. Can a website migration be free?
A provider may include a supported migration as part of a hosting arrangement or offer a self-service tool without an extra transfer charge. Check eligibility, method, and remaining responsibilities. Hosting, software, client review, excluded feature work, and later support can still have a cost. A free transfer fee should therefore be compared with the complete result the business needs, rather than interpreted as proof that every part of the transition costs nothing.
3. How long does a website migration take?
The schedule depends on access, scope, implementation, reviews, final data, provider availability, and acceptance. Ask what starts the clock and what counts as completion. A tool’s copying duration is not the full project timeline, and an elapsed project period is not necessarily public downtime. The twelve-working-day model in this guide is a labeled scheduling illustration, not a standard duration for your site.
4. Why can two quotes for the same website differ so much?
The providers may be pricing different results, methods, assumptions, or levels of responsibility. One offer might cover a basic copy while another includes cleanup, feature rebuilding, URL decisions, current-data reconciliation, and handover. Rates and estimated effort can also differ. Use the same written brief and ask each supplier to identify included, excluded, client-supplied, and unresolved tasks before deciding which proposal costs less for an equivalent completed project.
5. Is a fixed migration fee better than hourly work?
The appropriate model depends on how well the project is understood. A defined scope can support a fixed fee; unresolved technical questions may suit bounded discovery or time-based investigation. Neither model removes the need for assumptions, acceptance, reporting, and change approval. Compare the complete commitment and the visibility it gives the business, rather than treating one pricing label as an automatic sign of value or risk.
6. Does page count determine migration pricing?
It is one input, but content patterns and exceptions matter too. Many consistent pages can be more repeatable than a small collection with custom layouts, galleries, unusual records, or complex features. If pricing is per page, define what the unit includes: import, formatting, media, metadata, links, review, and corrections may be handled differently. A representative sample helps establish whether page count describes the actual effort.
7. Does moving to WordPress include a redesign?
Only if redesign work is included in the proposal. A platform change can require new templates and feature implementation even when the business wants a familiar appearance. Developing a new visual direction adds separate decisions and review. Agree whether the project recreates an approved design, adapts a theme, or includes a new design process, and specify the representative templates and review rounds that support the estimate.
8. Are email and domain transfer included in a hosting migration?
Do not assume they are. Registration, DNS, website hosting, staff email, and website-generated messages are separate responsibilities even when one account bundles them. A provider may move the application while leaving domain registration and mail in place. If mailboxes or registration must move, include those tasks explicitly and confirm the source cancellation effect. The quote should identify what stays, what changes, and who verifies each service.
9. Does migration pricing include SEO work?
That depends on the stated scope. A URL-changing project may need content decisions, destination mapping, redirects, public-signal review, and monitoring. An unchanged-URL host transfer has different requirements. Ask which checks and corrections are included, who supplies the relevant access, and what post-launch observation covers. No particular fee or checklist can guarantee unchanged rankings; the useful commitment is a defined implementation and verification process.
10. Why might a migration take longer without adding many labor hours?
The calendar can be held by account access, client review, integration decisions, provider scheduling, or an available launch window. Waiting does not automatically equal billable full-time work. It can still affect reserved capacity or create another final-data task, so ask how the proposal handles those situations. Track the dependency that controls the next milestone instead of assuming that every elapsed day represents an equal amount of technical effort.
11. What happens if the provider discovers additional work?
The provider should describe the finding, affected scope, proposed correction, and price or schedule effect before treating it as an approved expansion. Distinguish a previously agreed deliverable that needs correction from a genuinely new requirement. The appropriate handling depends on the proposal’s actual assumptions and commercial arrangement. A discovery stage, representative sample, and clear change process make these decisions easier without pretending that every uncertainty can be eliminated upfront.
12. When should I cancel the old hosting or platform subscription?
After the destination is accepted and the remaining source dependencies are understood. Check current records, files, email, DNS, redirects, access, and recovery arrangements. Some services can end while others need to remain under named ownership and renewal control. A new homepage loading is not enough evidence to cancel everything. Record the retirement decision and its continuing costs so temporary retention does not become an unexplained permanent expense.
