White-Label XM Cloud Delivery: Scope, QA and Handover
In This Article
White-label XM Cloud delivery works best when the agency and engineering team agree the technical workstreams before a client milestone is promised. Content modelling, frontend implementation, integration and authoring tests are related work, but they do not have identical owners or completion criteria.
Use the Sitecore partner due-diligence guide for supplier selection. This guide concerns execution through the white-label Sitecore and XM Cloud service.
Establish the architecture and dependency inventory
Document the source platform, target frontend, content types, components and connected systems. Identify dependencies such as forms, search, identity, personalisation and existing custom modules. Have the agency and technical lead agree which capabilities are required for the first release.
Sitecore's official migration FAQ explains that existing MVC solutions need conversion for XM Cloud's headless delivery. Do not treat a successful content import as proof that the presentation application has been migrated.
White-Label XM Cloud Delivery: Scope, QA and Handover
White-label XM Cloud delivery should separate content migration, frontend implementation, integrations and release ownership. Agencies need authoring and engineering acceptance checks alongside a clear handover; moving content does not automatically convert an MVC application.
Separate content and frontend deliverables
Content work includes model decisions, field mapping, references, media and migration validation. Frontend work includes component behaviour, routing, rendering, data access and responsive presentation. Record how these workstreams meet and who resolves changes affecting both.
Use representative content to review components early. Confirm whether existing content can be reused, transformed or needs editorial work. Avoid assuming that every legacy template should be copied unchanged into the new implementation.
Give integrations explicit boundaries
For each integration, define the required behaviour, account owner, test environment and failure handling. Agree what stays in the first release and what is postponed. Connected services can affect both schedule and QA; they should not remain unnamed items under an all-inclusive migration label.
The XM Cloud development service is the specialist implementation journey. Agencies should describe their integration needs and the delivery roles they already provide before requesting additional engineering.
Discuss the scope and responsibilities for your project
Test authoring and customer behaviour
- Have editors create and update representative content.
- Check references, preview and publication across affected routes.
- Test navigation, permissions and integrations with realistic inputs.
- Verify metadata, internal links and approved URL mappings.
- Review mobile layouts and long content, not only short demo text.
Record defects against the agreed acceptance criteria. The agency needs a clear account of what has passed before it presents the release to its client. Technical completion and editorial acceptance should both be visible.
Define release gates and handover
Assign who approves the release, changes environments and handles rollback. Document deployment steps, account ownership, known issues and support responsibilities. Confirm who maintains the frontend and integrations once the initial project ends.
Support windows and response arrangements require their own agreement. Use the Sitecore development support service for that discussion. Do not infer continuous coverage from a developer or project package.
Keep the agency's client process explicit
Agree which engineers may join calls, how project updates are shared and who accepts client feedback. Provide technical evidence in a form the agency can review before forwarding it. That makes white-label delivery a concrete responsibility model rather than a promise that the partner can independently own every part of the client relationship.
Bring your brief and questions to the next discussion
Frequently Asked Questions
What should an XM Cloud delivery plan separate?
Separate content modelling and migration, frontend implementation, integrations, authoring, release and handover. Assign an owner and acceptance checks to each workstream.
Does content migration convert an existing MVC frontend?
No. Content transfer and application redevelopment are separate tasks. Assess presentation code and platform-specific dependencies for the target headless implementation.
What should editors test before acceptance?
Editors should test representative components, content changes, references, preview and publishing. Check that the rendered experience reflects the content and agreed permissions.
What should the white-label handover include?
Include repository and environment ownership, deployment instructions, dependency records, content-model documentation, known issues and responsibility for support after release.
