is migrating existing content and data out of scope?
Yes — migrating existing content and data is distinct from building the system that receives it, and unless your scope names it, it's additional work. The exception is a small, fixed set of content that was clearly part of the agreed build, like a handful of pages you were always going to populate.
Why this answer
Building a container and filling it are two different jobs. You can deliver a flawless new platform and still have done none of the work of moving years of accumulated posts, products, customer records, or media into it. Migration is its own discipline: auditing what exists, cleaning inconsistent or duplicated data, mapping old fields to new structures that rarely line up one-to-one, handling formats that don't transfer cleanly, and verifying nothing was lost or corrupted in transit. The volume is also unpredictable from the outside — 'move our content' might mean fifty items or fifty thousand, and the effort scales with both quantity and messiness. Old data is almost never tidy; it carries legacy quirks, broken links, and edge cases that only surface mid-migration. Pricing a build never accounts for excavating and reshaping a client's entire content history. When migration wasn't scoped, the client is asking you to take on a second project whose size you can't even confirm until you look.
When the answer flips
It leans In Scope when the content to be placed is small, defined, and obviously part of the build — populating the five pages you designed with the copy the client hands you isn't migration, it's finishing the deliverable. It's also In Scope if your contract named migration, in which case the only open questions are volume and quality of the source data. The genuinely ambiguous zone is partial migration: you agreed to move 'the main pages' but the client now reads that as the entire archive. When the agreed language named a bounded set, hold to that set; when it gestured vaguely at 'the content' without limit, you're owed a conversation about volume before anyone assumes the whole history is included. Source-data quality can also shift the picture — clean, structured data is a fraction of the work that messy, inconsistent data demands.
What to do next
Don't quote migration blind — ask to see the source first. Get a real count and a sample so you can judge volume and how clean the data is, because those two factors drive the price more than anything else. Quote it as a separate project with its own timeline, and structure the fee around effort: a flat rate if the data is uniform and tidy, a tiered or per-record rate if it's messy enough to need cleanup. Useful framing: 'Building the new site and moving your existing content are two jobs — once I've seen the current data I can scope the move; expect it to be [range] depending on how clean things are.' Offer options: a full white-glove migration, a structured export you hand back for the client to import themselves, or a partial migration of the highest-value content with the rest left to them. And carve out who's responsible for verifying completeness once the move is done.
Frequently asked questions
Isn't moving data automatic if both systems are modern?
Almost never fully. Even with good export and import tools, the two systems model data differently, so fields rarely map one-to-one. You still handle format mismatches, broken references, media that doesn't transfer cleanly, and the inevitable records that don't fit the new structure. Automation handles the bulk and you handle the exceptions — and the exceptions are where the time goes. 'Modern' reduces the manual work; it doesn't eliminate the judgment.
How do I price a migration when I don't know how much data there is?
You don't — you look first. Ask for a record count and a representative sample before quoting, because volume and data quality swing the price enormously. Once you've seen it, price a flat fee for clean, uniform data or a tiered rate when cleanup is involved. Quoting migration sight-unseen is how you end up eating a five-figure cleanup job you bid as an afternoon's work.
The client says it's just copy and paste. How do I respond?
Show them the gap between volume and effort. Copy and paste works for ten items; it collapses at a thousand, and it does nothing for data that needs reformatting, deduplicating, or restructuring to fit the new system. Offer the honest tradeoff: they can do the manual paste themselves for free, or you migrate it properly for a fee. Most clients choose to pay once they grasp the scale.
What if the old data is a mess — broken links, duplicates, missing fields?
Then cleanup is a real and chargeable part of the job, and you should name it explicitly. Decide upfront whether you're migrating the mess as-is or cleaning it on the way through, because those are very different prices. Often the best move is to quote a basic migration plus an optional cleanup tier, so the client chooses how much polish they're paying for rather than discovering the cost mid-project.
Who verifies that everything moved over correctly?
Agree on this before you start. You can verify against record counts and spot-check samples, but confirming that every individual item is correct and complete is often work the client is best placed to do, since they know their own content. Define a clear handoff: you deliver the migrated set with a verification summary, and the client signs off after their review. Leaving verification undefined is how 'you lost a record' disputes start.
Can I just hand them an export and let them import it?
Often yes, and it's a good middle option. A clean, structured export the client imports themselves costs you far less than a full white-glove migration and gives them a cheaper path. Be clear about the boundary: you provide the export in a usable format, and the import plus any issues on their end are theirs. Offering this alongside a full-service quote lets the client trade money for their own effort.
Related reading
- The full guide
The scope creep guide for freelancers
How to spot scope creep, why clients do it, what it costs you, and how to respond professionally.
- Scenario
is a payment or crm integration out of scope if it wasn't agreed?
Yes — an integration with a system that wasn't named in your scope is new work, often substantial, because it pulls a third party's API, ed…
- Scenario
is an extra page out of scope when the count was agreed?
Yes — if your agreement names a page count, anything beyond it is additional work, even when the client calls it small. The exception is wh…
- Clause guide
What a deliverables clause should include in freelance contracts
A strong deliverables clause names each artifact with a format, a quantity, and — critically — an exclusion list. If it's not named, it's n…
- Profession guide
Scope creep for web developers: where projects actually break
Web development scope creep usually hides in the gap between 'build this feature' and 'make it work in production.' Clients think the featu…
- Scenario
is content entry out of scope?
Yes — typing the client's content into the system you built is a distinct, time-consuming task that's separate from designing or building t…
Answer scope creep from your actual contract — not a template.
Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.