Shopify Hydrogen Agency Handoff Checklist: What Your Client Should Be Able to Do After Launch

Launch is only the technical milestone. The handoff is complete when the client can handle routine storefront work, recognize when a request needs development, and follow a clear escalation path when something goes wrong.

If the project is still in discovery or pre-launch planning, start with the Shopify Hydrogen migration checklist before using this handoff guide.

The operating model is straightforward. Shopify remains the commerce backend. The Hydrogen storefront remains code.

Weaverse gives merchant teams visual control over the pages, sections, and settings developers choose to expose.

This guide turns that model into a practical handoff test. Use it to verify what the client can do, document what the agency still owns, and close the gaps before post-launch support begins.

For the rationale behind visual editing on Hydrogen, read Why Shopify Hydrogen Teams Need a Visual Builder.

Define the operating boundary

A useful handoff starts with a boundary map: what merchants can change, what developers own, and how a request moves between the two.

In a Weaverse project, developers build and register storefront components. Their schemas define the controls available to editors, such as headings, images, button labels, collection pickers, colors, spacing, or selected layout options.

Merchant teams can work independently inside those controls.

Changes outside that model still need development. Common examples include a new component, application logic, a data integration, route behavior, or responsive behavior that the schema does not expose.

Use this rule during training:

If the option is available in the approved editor controls, the content team can use it. If it changes storefront behavior or is not available in the schema, send it to the development owner.

That division gives merchants room to move without turning developers into the publishing team. It also prevents visual editing from being presented as unrestricted no-code development.

What clients should be able to do

Ask the client to complete these actions during a live handoff session. Watching someone perform the workflow reveals gaps that a walkthrough or document often misses.

Edit supported content and media

Start with an existing page and ask the editor to:

• Replace short and long copy.
• Update a button label and destination.
• Replace an image or other supported media.
• Check alt text, crop, focal point, or responsive settings when available.
• Select a product or collection when the component provides a Shopify resource picker.
• Restore the original content.

The editor does not need to memorize every field. They should understand how the page is structured, work confidently inside the available controls, and notice when a request falls outside them.

Assemble a page with approved sections

If the implementation supports page assembly, the client should be able to add an approved section, configure its required fields, move it into position, and remove it again.

Document the constraints that are easy to miss. Some sections may only work on certain routes or with a specific parent or data source. Others may require minimum image dimensions, copy limits, or particular combinations of child elements.

The component library should make routine assembly safe, but it cannot make every section appropriate in every context.

Review a realistic preview

Ask the editor to review the page on desktop and mobile, follow critical links, and test content likely to wrap, crop, overflow, or disappear on smaller screens. Product and collection sections should use real Shopify data, including an unavailable product or empty state when relevant.

Code previews and content previews serve different workflows.

On Oxygen, each Hydrogen deployment is an immutable code snapshot with its own preview URL. A content preview shows editor changes within the deployed storefront.

The client should know which one they are reviewing and what approval it represents.

Publish and verify the live result

Document one publishing path for the team:

1. Make the change in the supported editor.
2. Review the agreed devices, locales, links, and data.
3. Get internal approval when required.
4. Publish through the documented content workflow.
5. Open the public URL in a fresh browser session.
6. Confirm the expected content, media, links, and Shopify data.

A publish confirmation is not the final check. Verify the page customers can actually see.

Know when to ask for development support

The content team should escalate changes involving:

• New components or settings that are not in the current schema.
• Cart, search, account, checkout, analytics, consent, SEO, or route logic.
• New integrations or data sources.
• Performance, accessibility, or responsive behavior outside the supported controls.
• Storefront errors, failed builds, deployment problems, or broken preview connections.
• Environment variables, tokens, domains, hosting, or other sensitive configuration.

A useful request includes the page URL, environment, expected and actual results, reproduction steps, screenshots, and the time of the issue. Include diagnostic context, never credentials.

Separate content publishing from code deployment

Write both workflows into the runbook and demonstrate them during handoff.

Publishing content in Weaverse does not trigger a Hydrogen code build.

Deploying a new component does not publish a marketer's draft.

Both workflows meet in the running storefront, so each needs its own approval and verification step.

Content and code also need separate recovery procedures. Document and test both in the handoff runbook.

Build the agency-to-client handoff runbook

Handoff problems are often small operational gaps rather than dramatic technical failures: the production domain sits in an agency-owned account, nobody knows which environment is live, or editors confuse a preview with the public page. A short runbook with named owners closes those gaps.

1. Record account and service ownership

List the business owner, operational owner, and client-controlled account for:

• Shopify organization, store, and Hydrogen storefront.
• Source repository and CI/CD workflow.
• Hosting environments and domain or DNS provider.
• Weaverse project and publishing workflow.
• Analytics, consent, search, reviews, email, loyalty, and other integrations.
• Error monitoring, logs, uptime checks, and alert destinations.

Include billing, renewal, administration, and support responsibility where relevant. Production should not depend on an individual agency employee's login or inbox.

2. Transfer access securely

Use each service's invitation and role-management flow. Give day-to-day editors the access they need and limit administrative access to a small, documented group.

Keep credentials out of handoff documents, tickets, email, and recorded training. Store secrets in the client's approved password manager or secret-management system. If a token may have been exposed, rotate it through the relevant service.

3. Define support and escalation

Name the owner and support channel for routine content questions, component changes, production defects, Shopify data issues, integrations, hosting, domains, and security incidents.

Add response expectations, severity definitions, and the information required in a report. If launch support or warranty coverage ends on a specific date, explain what support looks like afterward.

4. Assign maintenance

Confirm who owns dependency updates, Hydrogen and Storefront API compatibility, accessibility, monitoring, integration changes, regression testing, and documentation.

The storefront foundation also shapes that maintenance scope. If the client needs context on the original implementation decision, point them to the comparison of a Hydrogen theme vs. a custom build.

The work can stay with the agency, move in-house, or be shared. What matters is that every responsibility has an owner and a trigger, such as a scheduled review, platform change, security advisory, failing monitor, or request for a new campaign capability.

5. Test both recovery paths

For content recovery, document the history or restoration capability available on the client's actual Weaverse plan and project. Test the approved process with non-critical content. If it has not been tested, record that limitation and the escalation route.

For code recovery, identify the repository strategy, deployment owner, production environment, and known-good version. On Oxygen, verify an older deployment and its configuration before making it current.

A recovery procedure is ready when the team has tested the result on its actual setup.

End with a client-led acceptance exercise

Give the editor one realistic campaign request that combines content editing, page assembly, mobile review, publishing, and live verification.

Then change the scope. Ask what would happen if the campaign needed a new layout or integration.

Ask the technical owner to locate the repository, identify the production environment, explain the deployment approval path, name the support contact, and walk through the recovery decision without changing production or exposing credentials.

If the client cannot complete a step, add it to the handoff plan. The exercise has done its job by finding the gap before the agency steps away.

Copyable Shopify Hydrogen handoff checklist

Use the guidance above during training, then copy this checklist into the project handoff document to track sign-off.

Merchant and content operations

• Editors can update supported copy, links, media, products, and collections.
• Editors understand that component schemas define the available controls.
• Editors can add, remove, and reorder approved sections where supported.
• Special constraints for sections, routes, and content are documented.
• Editors can review desktop, mobile, locales, links, media, and real Shopify data.
• The content approval and publishing path is documented.
• Editors verify the public storefront after publishing.
• The team knows which requests require developer support.

Code and deployment operations

• The client-controlled repository and production branch are identified.
• Code review, CI/CD, preview, and production deployment are documented.
• Production, preview, and custom environments are clearly named.
• Environment-variable ownership is documented without exposing values.
• Critical journeys and post-deploy checks are listed.
• Code recovery has been tested on the actual hosting setup.
• Content recovery has been tested separately.
• Rollback behavior has been verified before it is promised.

Ownership, security, and support

• The client controls the required Shopify, repository, hosting, domain, and Weaverse accounts.
• Billing and renewal owners are recorded for production services.
• Access was transferred through supported invitations and roles.
• Day-to-day users have only the access they need.
• Credentials and secrets are stored in an approved secure system.
• Support contacts, severity levels, response expectations, and warranty dates are documented.
• Maintenance ownership covers dependencies, platform changes, accessibility, monitoring, and integrations.
• The client has completed the final acceptance exercise.

A handoff tests the operating model

A successful handoff gives merchants control of routine storefront work without blurring the boundary between content and code.

That is the Weaverse model in one line: developers build the system; merchants run the storefront visually.

Before your next client handoff, try the Weaverse live demo to experience the Hydrogen editing workflow your merchant team will use after launch.

Sources

• Shopify docs: Hydrogen deployments
• Shopify docs: Hydrogen environments
• Shopify docs: Deploy from a custom CI/CD system
• Weaverse docs: Why Weaverse for Hydrogen
• Weaverse docs: Preview connection errors
• Related: Weaverse — Why Shopify Hydrogen Teams Need a Visual Builder