Key Takeaways
A finished build is not the same as operational control. Before sign-off, you need enough ownership, documentation and support clarity to run the site properly, change supplier if needed, and avoid post-launch disputes.
- Ownership: Admin access alone is not enough if the agency still controls the repo, deployments, integrations or analytics accounts.
- Handover: A usable pack should cover code, credentials, environment details, release process, training and known limitations, not just a promise to share things later.
- Warranty: It should fix defects in the agreed build, with clear reporting, triage and closure rules, rather than vague language about minor fixes.
- Support: Post-launch support needs named responsibilities for monitoring, updates, incidents, testing and rollback, especially in the first weeks after launch.
Many eCommerce teams discover after launch that they do not fully control what they paid for. The repo still sits with the agency. Production access is partial. Analytics is registered to the wrong account. Nobody can say with confidence who handles rollback if checkout breaks after a platform update.
The short answer: At handover, a buyer should receive source code ownership, all platform and integration credentials, deployment documentation, and a written warranty covering defects in the agreed build. Post-launch support must then define monitoring, incident response, update responsibility and rollback ownership – with SLAs confirmed in writing. Anything less leaves the original agency holding operational control they were paid to transfer.
That is not a clean handover. It is dependency dressed up as support. If you are choosing an agency for eCommerce development agency in London, ownership, warranty and post-launch support need to be defined before sign-off – not after the first incident.
This guide is for eCommerce leads, founders, operations teams and replatforming buyers who need clarity on ownership and support before final supplier selection or launch sign-off.
What ownership really means after launch
Whether you are running on Shopify, Magento, WooCommerce or a headless commerce architecture, ownership is not the same as being able to log in to the storefront. You need usable control over the source code, admin accounts, environments, analytics, tag manager, payment gateway dashboards and the release process. If the agency still controls deployment or holds key credentials, you do not have operational control in any practical sense.
Managed convenience versus dependency: some buyers are comfortable with the agency continuing to run releases and support. That can work – but only if the boundaries are explicit, access is genuinely shared, and you could move to another provider without rebuilding your operating model from scratch.
You should ask who owns the repo, who can access production, and who has authority to approve or reverse releases. Do not assume a finished build means you have operational control. In our experience, the hidden failure mode is rarely the design or checkout UX. It is the dependency sitting behind the release process.
A common example is a store where the client holds Shopify or Magento admin access, but not the integration credentials, deployment workflow or analytics ownership. On paper that looks fine. In practice, every future change still routes through the original supplier.
What should be in the handover pack before sign-off
If you want a proper handover, you need a usable pack – not a vague promise that everything will be shared once the invoice clears. You should be able to operate the site, brief another provider if needed, or stay with the same agency by choice rather than through lock-in.
Before you approve final sign-off, check that the handover covers code, access, documentation, training and support boundaries. If any of that is missing, push on it before the last payment is made. This is also where reviewing what should be included in the development scope before signing becomes useful – because weak handover terms almost always start as weak scope terms.
WEBDIGITA eCommerce Handover Checklist: use this to test whether the project is genuinely ready for sign-off or only looks finished on the surface.
- Code and assets: source code transfer or confirmed ownership, theme files, custom app or module code (including Shopify apps, Magento extensions or WooCommerce plugins), and design files.
- Access and credentials: platform admin, CMS, hosting or cloud access where relevant, repo access, payment gateway dashboards, analytics, tag manager, and key integration accounts.
- Documentation: deployment process, environment details, integration map, key dependencies, known limitations, and routine update ownership.
- Operational readiness: training for internal users, release ownership, rollback plan, and a named escalation route for launch-period issues.
- Commercial boundaries: written warranty terms, support scope, exclusions, SLAs, and what counts as chargeable change work.
Ask for documentation that another technical team could actually use. That means not just credentials, but enough context to understand how inventory sync, payment gateways, CMS integration or custom checkout logic behave in your specific build. If you are dealing with a complex architecture, a project discovery workshop in London can surface these ownership and scoping gaps before they become post-launch arguments.
Not sure your handover terms cover real operational control
We can review your launch, warranty and support terms before sign-off, so you can spot access gaps, weak ownership wording and hidden dependency risks early.
Useful before contracts are signed or launch is approved
What the warranty should fix – and what it should not
A warranty corrects defects in the agreed build. It is not an open-ended bucket for new features, content changes, campaign requests or third-party issues that surface after launch. Without that distinction confirmed in writing, every post-launch problem becomes a negotiation about scope.
The questions to ask before sign-off are straightforward: how are bugs reported, how are they reproduced, who triages them, and how is closure confirmed? Watch for terms like “reasonable support” or “minor fixes included” with nothing defined behind them. If the supplier cannot describe the triage workflow, the warranty is softer than it sounds.
Having reviewed post-launch operations across Shopify, Magento and WooCommerce builds – and on headless commerce architectures where integration dependencies run deeper – the pattern is consistent: when handover documentation is incomplete, the original agency retains practical control over the release cycle. Every fix, test and deployment still routes back through them. That is not an ongoing relationship. It is a structural dependency that slows every future change cycle, raises the cost of switching supplier, and makes the warranty period harder to enforce than it should be. Warranty and handover cannot be treated as separate admin tasks – they are the same problem.
- Usually included: defects against agreed functionality, broken templates, failed integrations caused by the delivered build, and launch-related issues within the defined warranty period.
- Usually excluded: new features, content population, third-party platform outages, plugin or module updates outside scope, and changes caused by internal teams or other suppliers.
- Needs explicit wording: checkout UX regressions, payment gateway failures within the delivered integration, inventory sync errors, analytics misfires, emergency fixes outside business hours, and release rollback responsibility if a deployment damages revenue-critical functions.
Do not assume “bug fix” covers you unless defect criteria are defined. I would push especially hard on edge cases where the issue sits between platform behaviour, custom code and a third-party integration – because that is precisely where vague warranty language leaves buyers exposed.
What post-launch support should cover – and what vague clauses usually hide
Post-launch support should describe who does what when the site is live and something breaks, drifts or needs maintaining. That means monitoring, incident response, update responsibility, security patching where relevant, release support, escalation routes and response times. CMS integration behaviour, payment gateway stability and inventory sync health should all have named owners. If those points are missing, you are not buying support. You are buying hope.
You need to understand the difference between warranty, maintenance and change work. Warranty fixes defects in what was delivered. Maintenance covers ongoing care – updates, monitoring, operational stability. Change requests are new work, whether a feature, integration amendment, design update or reporting change.
Watch for clauses that quietly shift risk: undefined fair use, no named SLA, no ownership of routine updates, no clarity on who tests releases, and no rollback responsibility if a deployment damages checkout or tracking. If you see soft language around an “ongoing partnership” with no operational detail behind it, treat it as a warning sign until the specifics exist in writing.
For a safer post-launch model, ask for named responsibilities across the first few weeks: who monitors orders, who checks analytics, who handles failed integrations, who approves releases, and who responds if checkout stops converting. Buyers comparing agencies often skip this question, so it is worth reading about how to choose an agency that can support the build properly after launch.
If the store will need structured ongoing support, ask what website maintenance services are included before you sign. You should leave the contract stage knowing exactly what happens after launch, who owns the moving parts, and where paid support begins. That conversation is far cheaper before sign-off than after the first broken release.
Related reading: why eCommerce projects go wrong before build even starts.
Questions buyers ask about eCommerce handover and post-launch support
These are the points worth clearing up before you approve sign-off or commit to an agency.
1. What should an eCommerce website handover include?
An eCommerce website handover should include code ownership or transfer, platform and repo access, hosting or environment details, analytics and tag manager ownership, payment and integration credentials, deployment documentation, training, and clear support boundaries. The real test is whether your team or another supplier could operate the site without relying on undocumented agency knowledge.
2. Is platform admin access enough to say you own the site?
No, platform admin access is not enough to prove real ownership. You also need control over the source code, production access, deployment workflow, analytics accounts, payment gateway access and key integrations. If those sit with the agency, the site may be live but your operating control is still limited.
3. What is the difference between warranty and post-launch support?
The difference is that warranty covers defects in the agreed build, while post-launch support covers ongoing operational help once the site is live. Warranty should deal with things delivered incorrectly. Support should define monitoring, maintenance, updates, incident response, testing, escalation and release responsibilities after launch.
4. What should be excluded from an eCommerce website warranty?
An eCommerce website warranty should usually exclude new features, content updates, campaign requests, third-party outages, and platform or plugin changes outside the agreed scope. The important part is not just the exclusions themselves, but having them written clearly enough that checkout issues, tracking problems and integration failures do not become grey areas.
5. Why do handover problems often show up after launch rather than before?
Handover problems often show up after launch because the site can appear finished while key operational details are still controlled by the supplier. The gaps usually surface during the first bug, failed deployment, analytics issue or integration problem. That is when teams realise access, rollback ownership and support responsibilities were never properly defined.
6. What should you ask an agency before signing off an eCommerce build?
You should ask who owns the repo, who can access production, who approves and reverses releases, what documentation will be provided, what the warranty covers, what support includes, and what becomes chargeable after launch. Those questions expose whether you are buying a stable operating model or inheriting hidden dependency.
Conclusion
The practical test is simple: if another competent team could not take over the store without confusion, the handover is not complete. The safest time to settle ownership, defect boundaries and support responsibilities is before final approval, while leverage still exists and assumptions can still be corrected.
| Check before sign-off | Why it matters |
|---|---|
| Who controls code, production and key accounts | Prevents hidden dependency on the original supplier |
| What the warranty fixes and excludes | Stops revenue-impacting issues turning into scope arguments |
| Who handles monitoring, releases and rollback | Reduces confusion when something breaks live |
| What becomes chargeable after launch | Lets you judge support value with clear commercial boundaries |
Need eCommerce support that stays clear after launch
If you want defined ownership, release responsibility, update coverage and practical post-launch support, our eCommerce maintenance service is the best next step to review.
View maintenance serviceNot sure what you need
