Digital Commerce Handover: Prove You Control the System Before Project Close

A practical acceptance checklist for businesses taking control of a website or commerce system: accounts, source, data, integrations, analytics, recovery and supplier exit.

TonyTradePublished 2026-09-20

A crystalline digital core crossing a glass bridge from an unfinished structure into a secure illuminated vault

The direct answer: accept a system only when your business can control, operate, recover and transfer it

A website or commerce platform is not fully handed over because it is online or because an administrator password exists. The receiving business should be able to control the critical accounts, operate the agreed customer journey, recover from a tested failure and appoint another qualified supplier without losing its domain, data or release history.

Turn those four outcomes into executable acceptance tests. Name the evidence, the person who verifies it and the owner who remains responsible after project close. A presentation or feature list is useful context, but it is not a substitute for testing from accounts controlled by the receiving company.

Map every dependency before checking access

List the domain registrar, DNS, CDN, hosting or cloud account, source repository, deployment service, content system, product and order data, forms, business email, CRM, payment connection, analytics, Search Console, licences, backups and monitoring. Record which legal entity owns each account, who pays it, who holds owner-level permission and how renewal or recovery works.

Do not treat all access as equivalent. Viewing a dashboard, editing content and controlling billing or ownership are different rights. For Google Search Console, for example, an owner can add or remove users and configure settings, while user permissions are narrower. The acceptance record should state the level actually verified.

Use invitations, role-based access and a company-controlled password vault. Do not exchange raw production passwords in ordinary email or place secrets in the handover document.

Prove control from company-owned accounts

Use a new browser session signed in as the receiving company, not as the supplier. Confirm that authorised staff can reach the registrar, hosting, repository, CMS, analytics and support channels. Check that recovery email addresses, multifactor authentication and billing contacts belong to the business or to approved accountable people.

Remove obsolete test users and document any supplier access that must remain. Supplier access can be legitimate for maintenance, but its scope, expiry and revocation path should be explicit. A named emergency route should exist if the person who set up an account is unavailable.

For GA4 and Search Console, verify the correct property or data stream, ownership level, data retention and links. Access to the wrong property is not evidence that measurement has been handed over.

Receive a reproducible release, not only a copy of the files

The handover should identify the source repository, production commit or release tag, build and deployment procedure, environment requirements, dependency inventory and configuration boundaries. Secrets should be referenced by their managed location rather than copied into source code or a document.

NIST’s Secure Software Development Framework recommends protecting code from unauthorised access, using version control, preserving release files and recording provenance. For acceptance, ask a competent person who did not perform the original deployment to follow the documented procedure in a safe environment. Record gaps instead of guessing around them.

Archive the accepted release, database schema and required migration steps. A zip file without a known version, dependency record or deployment path may be a backup of files, but it is not yet a maintainable release.

Run one complete commercial journey

Choose a path that represents value to the business: discover a product, read the correct market and language information, submit an enquiry or order, receive the message in the intended business system and assign it to a responsible person. Confirm consent, status messages and error handling as part of the same path.

Use controlled test data and remove or label it afterwards. Check the interfaces that can silently break: form-to-email delivery, CRM mapping, product identifiers, tax or shipping rules, payment status, inventory reservations and webhook retries. The exact test set depends on the system; mark features that are outside scope rather than pretending they passed.

Accepting a page because it renders does not prove that the operating team can complete the business task behind it.

Verify measurement with a real event

Open the site through an agreed test route and create one clearly labelled event, such as a test enquiry. Confirm the event is visible in the correct GA4 stream and that the business record reaches the system of record. Then verify that internal and automated traffic is filtered according to the documented rule.

Check that the company has appropriate access to GA4 and Search Console and that the website references the intended measurement identifiers. Document which events represent registration, enquiry and purchase, how they are deduplicated and what consent or regional controls apply. A tracking script present in HTML is not proof that a conversion event is trustworthy.

Demonstrate restore and rollback

Identify what is backed up, where it is stored, how often it runs, how long copies are retained and who can restore them. Select a safe restore target and demonstrate that a representative backup can be opened and used. Record the recovery point and the time required; a green backup status alone does not prove recoverability.

Document the last known good release and the rollback decision path. Test a non-destructive rollback or recovery rehearsal where practical. Include DNS, certificates, scheduled jobs and external configuration when they are required for service restoration, because application files alone may not recreate the system.

Agree which incidents require the original supplier, which can be handled by the receiving team and which depend on a third party.

Make data export and supplier exit testable

Export a representative set of content, product, customer, order or enquiry data within the agreed scope. Check field names, identifiers, media references, character encoding, timestamps and relationships. A spreadsheet that loses product variants or order links is not a complete exit path.

List proprietary components, third-party licences and services that cannot be transferred directly. State the replacement or renewal action and its deadline. Confirm who retains data after handover, what must be deleted and which records must remain for legal or operational reasons.

An exit test is not an accusation against the current supplier. It is evidence that the business asset can survive normal organisational change.

Use an evidence-based acceptance matrix

For each item, record the asset, required control, test action, expected result, actual result, evidence location, owner, status and retest date. Useful statuses are pass, fail, accepted exception and not applicable. Avoid a single percentage score that hides a failed domain, recovery or data-control requirement.

Do not close critical failures by promising to document them later. Classify severity before the project ends: loss of domain control, unavailable source, failed restore and broken lead or order routing usually deserve a clear resolution or a formally accepted continuity plan.

After acceptance, schedule owner and access reviews, restore rehearsals, licence renewal checks and monitoring reviews. Handover is the start of operational accountability, not the end of maintenance.

Common mistakes to catch before sign-off

Common mistakes include letting a supplier own the domain, sharing one administrator account, accepting screenshots as proof, receiving unversioned source, never testing a restore, leaving analytics in the supplier’s property, overlooking paid licences and failing to test data export.

A smaller system with demonstrated control is safer than a larger feature set the business cannot maintain. When evidence is incomplete, keep the project open with named actions and dates rather than declaring the infrastructure finished.