How We Handle Client Data During a CMS Migration
Security and procurement teams evaluating a CMS migration eventually ask a question most sales presentations do not answer in enough detail: what exactly will the agency be able to see, copy, and access while working with company data? “We take security seriously” is not a useful answer on its own. Reviewers need to see the access model, data flow, retention rules, sub-processors, and offboarding process behind that claim.
eight25 is a Contentstack partner and a listed Contentful Solutions Partner. Our enterprise migration work includes NetApp’s move from SAP RWS Tridion to Contentstack: roughly 14,000 pages across 10 languages on a Next.js, Vercel, and Akamai architecture. We have also supported enterprise engagements subject to formal vendor-security review. What follows is the data-handling model we use to plan that work, so clients can evaluate us and other migration partners against specific controls rather than broad assurances.
What “Client Data” Actually Means in a Migration
The phrase sounds like one thing, but it covers several categories with different confidentiality, integrity, and privacy risks. Published website content may be relatively low sensitivity, but a CMS can also hold embargoed material, personal data, unpublished assets, configuration details, and records retained by custom integrations. The first step is therefore to inventory the data instead of assigning one risk level to the CMS as a whole.
| Data category | Examples | Real risk if mishandled |
|---|---|---|
| Content estate | Published and draft pages, assets, PDFs, metadata | Integrity and availability risks, plus confidentiality risk where drafts, internal metadata, embargoed content, or personal information are present |
| Credentials and access | CMS administration, DAM, SSO, CDN, translation, hosting, and analytics | High-impact risk: an overprivileged or unrevoked credential can expose multiple systems and remain usable after the project |
| Embedded PII | Form submissions, gated-content leads, author records, comments | Regulatory exposure (GDPR, CCPA); often discovered mid-migration, not scoped |
| Pre-release business information | Unannounced product pages, draft press releases, embargoed campaigns | Confidentiality and commercial risk; staging or preview environments can expose the material before publication |
| Configuration and integration data | API keys, webhook targets, personalization rules, redirect maps | Quietly sensitive; an exported config file is a map of your infrastructure |
Published content may represent most of the volume, while credentials, embedded personal data, configuration records, and pre-release material often create the more consequential exposure. Encrypting transfers is necessary, but it does not answer who can access the data, where working copies are stored, how long they are retained, or how credentials are revoked.
Embedded personal data deserves specific attention during discovery. Legacy platforms can accumulate form submissions, gated-content records, account details, comments, and author information that are no longer understood or actively governed. We therefore document what personal data exists, whether it is still needed, the lawful and operational reason for retaining it, and where each category should live after migration. Deciding what not to migrate is a data-minimization and retention decision, not merely a scoping decision.
The Access Model: Named People, Least Privilege, Tracked Provisioning
Ask an agency who will have access to your systems and you will often get a headcount, not a list. Access should attach to named individuals, because revocation, audit logs, and accountability all break when logins are shared.
eight25 assigns a named delivery pod to each engagement and documents which individuals require access to each client system. Pod composition varies with the scope, but access is provisioned to approved individuals rather than shared generically across the agency. The client’s security team can review the access matrix at kickoff and whenever the assigned personnel or required systems change. A typical matrix looks like this:
| Role | Systems accessed | Highest environment |
|---|---|---|
| Migration engineer | Legacy CMS, target CMS, approved migration tooling | Read access to source; scoped write access to non-production; temporary production access only where required for an approved cutover task |
| Front-end developer | Target CMS content model, source repository, build system, and hosting platform | Non-production by default; production deployment rights limited to the approved release process |
| QA specialist | Preview or staging site, scoped CMS access, test results, and analytics where required | Read-only access wherever practical; no production write access |
| Project lead | Project tooling, status dashboards, and scoped CMS visibility where required | Read-only access based on delivery responsibilities |
| Client-approved deployer | Production deployment pipeline and release controls | Time-bound production access for the approved cutover or release window |
Two things in that table matter more than the rest. First, production access is not a standing grant; it opens for the cutover window and closes after it. Second, read access and write access are separated on the legacy platform, because the source system must remain a stable, untouched baseline for reconciliation.
The operational reality most vendors gloss over is that enterprise access provisioning is slow, and that slowness is a feature. On the NetApp migration, per-system credential regimes, including CyberArk-managed privileged access, SSO, and enterprise translation credentials for Trados, were the recurring gating item. The fix was not to route around the controls. It was to treat access provisioning as a tracked workstream from week one, with dedicated technical sessions per system and a named owner for each grant. If an agency tells you provisioning friction won’t affect the timeline, they are either planning to bypass your controls or they have not done this at enterprise scale.
Three requests deserve additional scrutiny: standing production write access without a documented migration or cutover task; analytics administration when a scoped read role would meet the stated need; and shared human accounts where individually attributable access is available. Some migrations do require time-limited production actions during cutover, but those grants should be approved, logged, narrowly scoped, and revoked when the task ends. Named accounts strengthen attribution and revocation, alongside centralized identity, logging, and periodic access review.
Where the Data Actually Moves: Environments and the Staging Problem
Content in a migration flows through a defined promotion path: legacy source, migration tooling, target CMS development environment, staging, production. What we prohibit is the undefined sixth location: the ad-hoc export. No content dumps to personal drives, no spreadsheet of form submissions emailed “for reference,” no local database copies that persist after the task that justified them. Working extracts live in the project’s agreed storage, encrypted in transit and at rest, and get deleted on a schedule someone owns.
This is where a headless architecture can provide a governance advantage when it is designed deliberately. Content, presentation, identity, customer records, and delivery infrastructure can be separated into distinct services with narrower permissions and clearer ownership. eight25 uses those boundaries to limit which systems each migration role can reach and to keep transactional personal data outside the content platform where practical. The separation does not make a headless implementation secure by default; it makes access and data flows easier to constrain, document, and review.
Staging deserves the same deliberate security review as production. It may contain a near-complete copy of the content estate, unannounced product information, integrations, test credentials, or personal data carried over from the legacy system. A guessable URL is not an access-control mechanism. Authentication, authorization, logging, data minimization, vulnerability management, and retention rules should be defined according to the sensitivity of what the environment contains.
Securing a staging experience can require controls outside the CMS itself. On the NetApp program, the requirement was to protect access to the rendered staging site—not simply access to the Contentstack application so eight25 implemented the gate at the Akamai edge layer. This illustrates an important headless principle: the CMS, front end, hosting platform, CDN, identity provider, and preview workflow form one security boundary. Controls must be placed at the layer that actually serves the protected experience.
Data-location requirements affect more than the target CMS region. The review should also cover migration tooling, backups, logs, asset storage, search indexes, analytics, support access, and relevant sub-processors. Confirm the required region, transfer mechanism, retention rules, and any exceptions in writing before personal or regulated data moves. Contentful and Contentstack both provide regional hosting options, but the selected region does not automatically govern every connected service in a composable architecture.
The Contractual Layer: What Should Be in Writing Before Kickoff
Process claims without contractual teeth are marketing. Before any agency touches a system, the paperwork should already answer the uncomfortable questions.
| Instrument | What it should cover | The question to ask |
|---|---|---|
| NDA and confidentiality terms | Pre-release business information, transaction-sensitive content, and roadmap material | “Does the agreement require equivalent confidentiality obligations for employees, contractors, and approved subcontractors with access?” |
| Data Processing Agreement | PII handling, sub-processors, breach notification window, deletion protocol | “What is your notification window, and who are your sub-processors?” |
| MSA security terms | Access management, encryption requirements, incident response, evidence, and audit rights | “What access records and security evidence will you provide, and what audit or review rights apply during the engagement?” |
| Offboarding clause | Credential revocation, working-copy deletion, certification of destruction | “What do you delete at handover, and will you certify it?” |
Two areas deserve extra attention. First, determine whether discovery activities including authenticated crawling, content exports, analytics review, or form-data inventory will cause the agency to process personal data on the client’s behalf. If they will, the applicable data-processing terms should be in force before that processing begins, rather than waiting automatically for the build SOW. Second, obtain enough subprocessor information to understand which entities will process the data, where processing may occur, how changes will be communicated, and what approval or objection rights apply under the governing law and contract.
The governance blueprint we produce in discovery maps these commitments to the actual architecture: which named person holds which grant, where working data lives, and what gets destroyed when.
For some organizations, the most defensible design keeps the migration agency outside the most sensitive data path. Where the legacy estate contains regulated customer, health, financial, or residency-constrained information, the client may choose to generate controlled extracts internally while the agency works with minimized, masked, anonymized, or synthetic data. In other cases, the agency can process the information under an approved DPA, access controls, retention schedule, and security architecture. eight25’s role is to help define the boundary and to say clearly when access is unnecessary not to assume that every available dataset should enter the migration workflow.
Offboarding: The Part Almost Everyone Forgets
A significant data-security risk can remain after the migration succeeds. The site launches, the retrospective ends, and a later access review discovers an API key or account issued to a supplier that no longer needs it. These orphaned credentials persist when the engagement defines provisioning carefully but assigns no owner, deadline, or evidence requirement to deprovisioning.
We define the ending before access is granted. The exact schedule depends on the engagement and the client’s security requirements; for example, the NetApp migration included a 30-day hypercare period. A typical access step-down works as follows:
- At cutover, temporary production deployment access expires at the end of the approved launch window unless an extension is documented.
- At the end of hypercare, migration-related write access is revoked. If eight25 continues under a support or managed-services agreement, any continuing access is separately approved and limited to what that service requires.
- At handover, every migration-era API key, service account, webhook credential, and named account is reconciled against the provisioning record. Ownership is transferred to an approved client representative or the credential is revoked or rotated. Working extracts are deleted according to the agreed retention schedule, and completion is documented in writing.
One question that should be answered explicitly is what happens when a pod member changes roles or leaves the engagement mid-project. The offboarding requirement should cover personnel changes as well as project completion, with a defined notification path, revocation deadline, and owner responsible for confirming that access has been removed.
The provisioning log is what makes both cases trustworthy. Because we tracked every grant as a workstream item on the way in, revocation is a checklist, not an archaeology project. The same ownership-transfer training and documentation that make your team independent of us also remove any operational excuse for our access to linger.
Frequently Asked Questions
What client data does an agency need access to during a CMS migration?
A migration partner typically needs read access to the legacy CMS and its asset store, admin access to the target CMS’s non-production environments, repository and hosting access for the new front end, and read access to analytics and redirect data. They should not need standing production access, direct access to your customer database, or copies of form-submission PII. If an agency’s access request includes systems it cannot tie to a migration task, ask why before provisioning.
How do I vet a CMS migration partner’s data-handling practices?
Ask for verifiable specifics: which named individuals will receive access, what the environment and promotion path looks like, how previews and staging will be protected, what incident-notification period applies, and how access and working copies will be removed. eight25’s model documents named access, applies least privilege, tracks provisioning as a delivery workstream, protects staging according to the sensitivity of its content, and reconciles credentials and working extracts at handover. The client receives written confirmation of the agreed offboarding actions. Any migration partner should be able to answer at this level of detail.
Should personal data be migrated into a headless CMS?
Only when there is a defined purpose and an approved control model. A headless CMS may legitimately process limited personal data, such as author accounts or carefully governed personalization attributes, but it should not become the default system of record for customer, lead, health, or financial information. A well-designed headless architecture makes this separation clearer: the CMS manages reusable content, while CRM, marketing-automation, identity, and transactional systems retain the records they are designed to govern. APIs can expose only the fields needed for a specific experience. This can reduce unnecessary duplication and limit the data exposed through the content layer, but only if permissions, integrations, logs, caches, and front-end applications are also secured. Migration discovery should document every personal-data category found in the legacy CMS and record whether it will be excluded, deleted, transformed, or moved to an approved destination.
What happens to the agency’s access after the migration launches?
It should end according to a documented, engagement-specific schedule. In eight25’s model, temporary production access expires with the approved cutover window, continuing access during hypercare is limited to the work being performed, and each migration-era account, API key, service account, and webhook credential is reconciled at handover. Credentials are revoked, rotated, or transferred to an approved client owner, and working extracts are deleted according to the agreed retention schedule. Ask every prospective partner to define this process before kickoff, including what happens when personnel change during the project.
Evaluating a Migration Partner Your Security Team Will Approve?
If a CMS migration is on your roadmap, an early scoping conversation should treat data handling as part of the architecture rather than paperwork saved for kickoff. eight25’s discovery process documents the proposed access matrix, environment path, data boundaries, and governance responsibilities before migration activity begins. That gives security and procurement teams concrete material to review earlier and reduces the risk of unresolved controls delaying delivery. We will also identify information and systems that eight25 does not need to access.