is uploading content to the cms out of scope?

They're describing their goal, not your scope, and the two aren't the same. From the client's seat, a site with no content isn't usable, so it feels unfinished — that's a fair feeling. But your deliverable was the system: the templates, the structure, the editing tools that make content possible. A built CMS with sample content demonstrating that it works is a complete system, even if the client's full library isn't loaded yet. Populating it is a distinct labor that scales with how much content they have, which is their variable. The honest reframe is to agree with their goal while separating the work: 'The system's done and working — getting all your content in is the next piece, and it's content population, which we should scope as its own task.' You're not refusing to help them reach a usable site; you're naming who does the data entry and at what price.

Enough to prove the build works, and no more. The purpose of sample content during a build is to demonstrate that the templates render correctly, the content types behave, and the editing interface is usable — a representative page or two per type usually does that. Once you're past 'demonstrating the system' and into 'transcribing the client's actual library,' you've crossed from build into migration, and the volume is what makes the difference. There's no magic page number, but the test is intent: are you adding content to show the machine works, or to fill the client's site so it can launch? The first is part of building; the second is population. If you find yourself formatting the client's tenth real page, you're doing migration, and it's worth pausing to scope it rather than letting it accumulate unbilled because each page felt small in the moment.

Pick whichever is genuinely cheaper for the volume and shape of the content, and bill it accordingly. Hand-entry makes sense for small or highly inconsistent libraries where every page needs human judgment to place correctly — automation can't easily clean up source material that's a mess in a hundred unique ways. A migration script makes sense when the content is large and reasonably structured, where the upfront engineering of an importer pays off across hundreds of records. Crucially, both are billable: hand-entry by volume or time, the script as engineering work. Clients sometimes assume a script is free because 'the computer does it,' but writing a reliable importer that handles the client's specific data quirks is real development. Estimate both paths, quote the cheaper one, and don't let the existence of an automated option turn into an expectation that migration costs nothing.

Not by default, and this is exactly where unscoped migration gets painful. There's a difference between loading clean content into the CMS and fixing content that's inconsistent, incomplete, or badly formatted before it can be loaded. The second is editorial cleanup — restructuring, rewriting, chasing missing images, reconciling contradictions — and it's a separate and often larger job than the entry itself. If you agreed to populate content, that fairly means content that arrives in a usable state, not raw material you have to repair first. When the source is a mess, flag it early: 'I can load your content, but a lot of it needs cleanup before it'll fit the structure — do you want to tidy it on your side, or should I quote that as editorial work?' Otherwise you absorb an invisible job that dwarfs the data entry you actually signed up for.

Often that's the best outcome for everyone, and it's worth offering as the default. The whole point of building a CMS is that content becomes manageable without a developer, so handing the client a working system plus a short guide on how to add content lets them self-serve at no extra cost. Many clients prefer this once they understand the volume — they'd rather spend their own staff's time than pay your rate for data entry, and they end up knowing their system better for having filled it. Make it easy: a clean editing interface, a brief written or recorded walkthrough, and your availability for genuine questions during a short support window. Reserve paid migration for clients who explicitly don't want to do it themselves or whose volume justifies automation. Self-service keeps the clerical work off your plate while still leaving the client fully served.

Then you priced against an unknown that turned out larger, and the honest move is to surface it rather than silently eat it. If you genuinely committed to loading the content but did so before knowing the volume, you share some responsibility for not quantifying it — but a tenfold surprise is a material change worth raising. Go back with specifics: 'When we scoped this I assumed roughly ten pages; it's turning out to be closer to a hundred, which is a different amount of work. Here's how I'd suggest we handle it.' Offer options — a change order for the extra volume, the client loading the overflow themselves, or an import script if automation now makes sense. Clients generally respond well to a clear, early, numbers-based conversation. The lesson for next time is to count the content before you quote, because 'all our pages' is a number that hides until you ask.