1. Establish ownership and access.
Identify the business owner of each account and the people who administer it. Confirm who controls the domain, DNS, hosting, CDN, repositories, Magento administration and key external services. Avoid a handover that depends on a departing supplier’s personal login.
- List the accounts, their business owners and existing access.
- Confirm billing and renewal responsibility for hosting, domains and extensions.
- Agree a secure access-transfer process and appropriate permissions.
- Record how previous supplier access will be removed after acceptance.
Do not exchange passwords in email chains or website enquiry forms. Ask the incoming team to describe its access process before transferring credentials.
2. Collect code, configuration and release instructions.
Obtain the source repository, current production revision and any uncommitted changes. Record custom modules, theme customisations and extensions, including why each exists and whether its licence can be used by the business.
Ask for a documented route from a clean checkout to a running staging environment. Include configuration requirements, deployment steps and the rollback procedure, while keeping actual secrets in an appropriate secure store. Production and staging should be clearly distinguished.
- Repository ownership, branches and the production release.
- Magento and PHP versions, dependencies and extension inventory.
- Environment configuration requirements and scheduled jobs.
- Build, deployment, testing and rollback instructions.
- Known defects, work in progress and upcoming upgrade decisions.
3. Map the systems around the store.
List payments, fulfilment, ERP, stock feeds, search, reviews, marketing and analytics connections. Record what each integration does, who owns it, how failures are detected and which team can resolve them.
For background jobs and imports, record frequency, source data and the business effect of a missed run. A healthy homepage does not establish that orders reach fulfilment or that stock updates are working.
4. Preserve trading knowledge.
Collect monitoring arrangements, incident contacts, support hours and the process for raising an urgent issue. Document backups and the known restore process. A backup existing is different from evidence that the store can be restored within an acceptable window.
Record upcoming campaigns, important trading dates and release restrictions. Include a short list of customer journeys to check after a change: search, product selection, basket, checkout and any store-specific features that affect orders.
Keep existing indexing and redirect behaviour in scope if the handover includes frontend or routing changes. Preserve access to Search Console and analytics so the incoming team can compare behaviour after releases.
5. Agree what completes the handover.
The incoming team should confirm it can access the agreed systems, understand the production revision and follow the release process. List missing information with an owner and a consequence. Then agree the date when support and release responsibility transfer.
Where practical, have both suppliers available for a bounded handover session. Review one representative change from ticket through deployment and discuss one past incident. That often reveals operational knowledge absent from a folder of documents.
A useful acceptance record includes:
- Systems received and access verified.
- Production revision and environment details.
- Release and rollback procedures reviewed.
- Known risks, gaps and their owners.
- Escalation contacts and responsibility-transfer date.
The checklist is a planning aid, not evidence that a particular store is ready to change suppliers. See Adobe Commerce maintenance guidance and discuss a scoped technical review if the platform’s condition is uncertain.