What we have seen in agency transitions is this: the missing item is rarely the Shopify login. It is the reason a decision was made, the edge case hidden in an integration or the release step known by one person. A safe handover transfers control and context before the outgoing team disappears.
This Shopify agency handover documentation checklist is for UK ecommerce leaders switching supplier, bringing work in-house or stabilising a store after a difficult engagement. If the transition is already at risk, Contact StoreBuilt.
Table of contents
- Keyword and competitor research
- What a handover must achieve
- The complete documentation checklist
- Access and security sequence
- The first 30 days
- Common handover failures
- StoreBuilt point of view
Keyword and competitor research
Primary keyword: Shopify agency handover.
Secondary keywords include Shopify handover documentation, switch Shopify agency UK, ecommerce agency transition and Shopify support handover. Search intent is urgent and bottom funnel. This operational checklist complements our broader guide to switching agency and routes to Shopify support, maintenance and audits.
Research on 5 August 2026 reviewed UK search results, Charle’s support and migration content structures, agency positioning from Charle, Swanky and Eastside Co, and StoreBuilt’s recent content. Existing guides discuss supplier selection and bad handovers; the gap is one implementation-ready transfer register.
What a handover must achieve
A complete transition should leave the merchant able to:
- control every critical account and contract;
- build and deploy the storefront;
- understand customer-facing commercial logic;
- monitor integrations and analytics;
- continue active roadmap work;
- reproduce known issues;
- respond to incidents;
- remove outgoing access safely;
- explain architectural decisions to the next team.
Do not measure completion by documents received. Verify that the receiving team can use them.
The complete documentation checklist
1. Ownership and access
| Area | Required record | Verification |
|---|---|---|
| Shopify | Organisation, stores, owners, staff and collaborator roles | Merchant owner can add and remove access |
| Domains and DNS | Registrar, DNS host, records and renewal | Merchant controls account and recovery |
| Email and notifications | Sending domains, templates and provider | Test sender and alert recipients |
| Source control | Repository, branches, actions and permissions | New team can clone, build and propose change |
| Hosting and services | Worker, app, database and storage accounts | Billing and recovery belong to merchant |
| Analytics | GA4, GTM, Search Console and ad platforms | Correct properties and admin roles confirmed |
Never send live passwords in a handover document. Use a password manager and transfer individual access with multifactor authentication.
2. Themes and code
Record the live theme, unpublished themes, repository-to-theme relationship, build commands, environment variables, deployment method, branch protection, third-party libraries and licensing.
Include:
- local setup instructions;
- naming and component conventions;
- custom Liquid, JavaScript and CSS areas;
- Checkout Extensibility and Shopify Functions;
- feature flags or market-specific behaviour;
- test and rollback procedure;
- known debt and browser limitations.
The receiving team should perform a clean build and deploy to a non-live theme before accepting the code handover.
3. Apps and contracts
For every app, state owner, purpose, billing plan, renewal date, data handled, theme/app-embed impact, webhooks, support contact and removal process. Identify overlapping apps and tools owned through the agency account.
4. Integrations and data flows
Document ERP, WMS, 3PL, PIM, CRM, helpdesk, subscriptions, reviews, loyalty, feeds, finance and custom APIs.
For each flow, record:
- system of record;
- direction and schedule;
- field mapping;
- authentication owner;
- retry and reconciliation;
- alerts and escalation;
- known volume limits;
- common failure modes;
- data-protection considerations.
An architecture diagram is useful, but operating instructions are essential. Someone needs to know what to do when ten orders fail to reach fulfilment at 4pm.
5. Commercial logic
Capture discount combinations, customer segments, Markets rules, price lists, subscriptions, bundles, preorder logic, gift cards, store credit, shipping, tax and payment exceptions. Link each rule to the Shopify surface or app that owns it.
6. Analytics and SEO
Transfer the event dictionary, consent behaviour, tag-management structure, dashboards, attribution assumptions and known data gaps.
For SEO, include:
- domain and sitemap setup;
- redirect register;
- canonical and robots conventions;
- structured-data ownership;
- international domains and hreflang;
- priority pages and current risks;
- Search Console access and annotations.
7. Delivery and roadmap
Provide active tickets, accepted requirements, designs, dependencies, supplier commitments, release calendar, peak-period freezes, outstanding defects and warranty items.
Separate facts from assumptions. “Nearly finished” is not a status; state what is built, tested, approved and still blocked.
Access and security sequence
Use a controlled sequence:
- inventory accounts and owners;
- create named access for the receiving team;
- verify build, analytics and vendor access;
- rotate shared secrets and recovery details;
- transfer billing and contract contacts;
- export required records;
- remove outgoing access after acceptance;
- monitor logins, deployments and integrations.
Do not remove the old agency on day one if they still own essential context or an active incident. Equally, do not leave indefinite administrator access after the relationship ends.
An anonymous StoreBuilt transition began with theme files but no reliable deployment map. The live theme contained changes that were not in the repository, while app configuration carried part of the customer journey. We first reconciled live and source states, documented the app-owned logic and established a safe release route. We cannot share the brand or metrics, but the key result was restored control—not a cosmetic redesign.
For rescue and continuity work, see StoreBuilt Shopify support.
The first 30 days
| Period | Receiving-team action | Evidence of completion |
|---|---|---|
| Days 1–5 | Access, ownership and store-state inventory | Signed access register and critical-risk list |
| Days 6–10 | Build, deploy and analytics verification | Non-live release and event comparison |
| Days 11–15 | Integration and commercial-logic review | Data-flow map and incident contacts |
| Days 16–20 | Backlog and known-defect triage | Re-scoped roadmap with dependencies |
| Days 21–30 | First controlled production change | Release note, monitoring and retrospective |
The first production change should be small enough to validate the operating model but meaningful enough to exercise requirements, QA, deployment and monitoring.
Common handover failures
- The agency owns the domain or repository.
- Theme files are supplied without build instructions.
- Passwords are pasted into a spreadsheet.
- Apps are listed without business purpose or removal impact.
- Integrations have diagrams but no alert and reconciliation procedure.
- Analytics access exists but event definitions do not.
- Open projects have no acceptance criteria.
- The old team is removed before knowledge transfer.
- The new team starts redesign work before stabilising delivery.
A handover is also a useful moment to reduce access and contract sprawl. Do not renew every tool automatically merely because it appears in the outgoing stack.
StoreBuilt point of view
StoreBuilt’s view is that the merchant should remain in control of its commerce system throughout every agency relationship. A good partner leaves a store easier to understand and safer to operate than they found it.
Treat handover as a verified operational release, not an exchange of folders. If you need an independent transition audit or a receiving team for the next phase, Contact StoreBuilt.