WineDirect to Commerce7: a migration checklist that protects your club

Platform migrations get quoted as technical projects and then fail for entirely non-technical reasons. The export runs fine. The import runs fine. Then the first club billing cycle after cutover produces a wave of declines, support gets buried, and months of goodwill evaporate over something that had very little to do with either platform.

The risk in this project is not in moving the data. It is in the decisions nobody made before the data moved.

This is the checklist I work from. It is sequenced deliberately: the order matters more than any individual item on it.

What actually breaks in a winery platform migration?

Four things, in descending order of how much damage they do:

1. Club billing. Members whose recurring charge fails, or bills twice, or bills for the wrong tier. This is the one that costs real money and real members.
2. Customer and order history. Lifetime value, purchase history, and club tenure that arrive incomplete, so the new platform cannot segment and your staff cannot answer basic questions on the phone.
3. Compliance and shipping rules. Rules that silently do not carry over, so you either block legal orders or accept ones you should not.
4. URLs. Every retired address that returns a 404 instead of a redirect throws away whatever search ranking it had accumulated.

Notice that the redesign is not on this list. The redesign is usually the visible part of the project and almost never the risky part.

What has to be decided before you pick a cutover date

Three decisions have to be settled in writing first, because each one changes the technical work underneath it:

Club tier structure. Are you carrying existing tiers across unchanged, or is this the moment you rationalize them? Both are defensible. What is not defensible is deciding halfway through the build, because tier structure determines the data mapping, the billing logic, the signup flow, and the member communication all at once.

Shipping and compliance rules. Which states, which carriers, and what happens to an order placed from a state you cannot ship to. Have the current rules written down as rules, not as "whatever the old system was doing." A surprising number of wineries discover during a migration that nobody remembers why a particular state is blocked.

Who owns the content rewrite. Product descriptions, club pages, the visit page. If this is unassigned it becomes the default reason the launch slips, because it is the one task with no obvious owner and no hard technical dependency forcing it to happen.

Settle these three and the rest is execution. Leave any of them open and you will be relitigating it during cutover week, which is the worst possible time.

Why is the club data the hard part?

Because everything else is a data move, and the club is a live financial relationship with a recurring obligation that keeps running while you migrate it.

Get an export that includes, at minimum:

• Member identity and contact details
• Tier, and the date they joined that tier
• Billing schedule and next scheduled billing date
• Payment method reference, and whatever token or profile ID the gateway uses
• Shipping preferences, including holds and alternate addresses
• Membership history: pauses, tier changes, previous cancellations
• Any credits, comps, or grandfathered pricing

That last item is the one that gets missed, and it produces the worst support conversations you will have. A member who has been getting a legacy rate for six years and suddenly is not will not read your migration announcement charitably.

Tenure is worth protecting specifically. If a member joined in 2019, the new platform needs to know that. Import everyone with today's date and you have destroyed your ability to segment by loyalty, along with any anniversary logic your retention work depends on.

Will club members need to re-enter their credit cards?

Possibly, and the answer determines your entire member communication plan, so resolve it early and get it in writing.

Payment credentials are held by your payment gateway, not by your ecommerce platform. The platform stores a token, which is a reference to a card the gateway holds. So the real question is not whether the new platform can import cards from the old one. It is whether you are keeping the same gateway, and whether that gateway will hand your tokens to a new integration.

Three possibilities:

• Same gateway, tokens portable. Best case. Members notice nothing about billing.
• Same gateway, tokens not portable to the new integration. More common than people expect. Members have to re-enter cards.
• Changing gateway. Assume re-entry unless the new gateway offers a migration service, which some will for an established book of business. Ask.

Do not accept a verbal assurance on this from anyone who is not the gateway. The cost of being wrong is every active member re-entering a card in the same week, and a meaningful share of them using the moment to reconsider the membership entirely.

If re-entry is unavoidable, plan it as a campaign with a deadline well ahead of the next billing run, not as a footnote in a launch email.

Products, inventory, and the mapping nobody budgets for

Wine catalogs are messier than they look, because one wine is often several things at once: a current release, a library vintage, a club allocation, a case configuration, and a tasting room SKU. Those relationships are encoded differently on every platform.

Before the import, produce a mapping document that answers, for every product:

• Which vintages are active, which are library, which are archived
• How bundles and case configurations are represented
• Which products are club-only or allocation-only
• Which are tasting-room-only and should never appear online
• What the inventory source of truth is after cutover

That last question causes more post-launch pain than anything else here. If the tasting room POS and the website disagree about how many cases of the 2021 remain, you will oversell something, and it will be the wine everyone wants.

How should compliance rules carry over?

Treat the compliance configuration as a fresh build validated against your license, not as a copy of the old settings.

Old platforms accumulate exceptions. A state gets blocked during a licensing lapse and never unblocked. A carrier rule gets added for one bad season and stays for five years. Migrating those settings verbatim carries the accumulated mistakes forward and, worse, makes them invisible again for another five years.

Test with real addresses in your highest-volume states before cutover, including at least one state you deliberately do not ship to, to confirm the block actually fires.

The redirect map

This is the item most likely to be skipped, and the only one here whose damage stays invisible for months.

Product pages, blog posts, and club pages will live at different paths on the new platform. Every old URL that returns a 404 discards the ranking and the inbound links it had earned. You will not notice on launch day. You will notice in the third month, when traffic is down and nobody can say why.

The process:

1. Crawl the live site before cutover. Not a list from memory, and not just a sitemap export. An actual crawl, so you catch the pages you forgot exist.
2. Pull your top landing pages from analytics and Search Console going back twelve months. These are the ones that must not break.
3. Map every old URL to a specific new one. Where there is no equivalent, map to the nearest relevant page rather than the homepage. A mass redirect to the homepage gets treated as a soft 404 and preserves nothing.
4. Implement as 301s, not 302s. A temporary redirect tells search engines to keep the old URL indexed.
5. Re-crawl after cutover and fix what you missed.

Keep the redirects permanently. There is no expiry date on a link someone published in 2021.

How should the cutover week be sequenced?

The governing principle: nothing irreversible happens until billing has been proven against real data.

• Build and import into staging using real exported data, not sample data. Sample data hides exactly the edge cases that matter.
• Reconcile record counts. Members, customers, orders, products. If the numbers do not match, find out why before proceeding. "Close enough" is how grandfathered pricing quietly disappears.
• Run a billing test. Whatever the new platform offers as a dry run of a club billing cycle, run it against the imported membership and read the output line by line. This is the single most important gate in the project.
• Validate compliance with live address tests.
• Freeze changes on the old platform. Pick a moment after which no new orders, member changes, or product edits happen there, and communicate it internally. Every change after the freeze is a manual reconciliation later.
• Run the final delta import covering everything between the main import and the freeze.
• Cut DNS, deploy redirects, verify. Redirects go live at the same moment as the new site, not the following week.
• Watch the first billing cycle. Assign a person to it. This is not the week to be on vacation.

Deliberately not on this list: launching during your busiest season, or during a club release. Pick the quietest month you have.

What to tell club members, and when

Communicate about consequences, not infrastructure. Members do not care which platform you are on. They care about four things:

1. Whether their membership continues unchanged
2. Whether they need to do anything, and by when
3. Whether their next shipment is affected
4. Where to go if something looks wrong

If cards transfer cleanly, one short note is enough and it should lead with "nothing you need to do." If cards do not transfer, that is a campaign: a clear deadline, multiple reminders, and a phone number for the members who will not do it online. Expect a portion of your book to need a human call, and staff for it in advance.

Send the first note before the change, not after. A member who discovers the migration by way of a failed charge is a member you now have to win back.

The checklist

Everything above, compressed:

Decisions, before anything technical

• Club tier structure confirmed in writing
• Shipping and compliance rules documented as rules
• Content rewrite owner named

Data

• Club export includes tenure, billing dates, credits, comps, grandfathered pricing
• Payment token portability confirmed by the gateway, in writing
• Customer and order history mapped, record counts reconciled
• Product mapping covers vintages, bundles, club-only, tasting-room-only
• Inventory source of truth decided

Search

• Full crawl of the live site captured
• Top twelve months of landing pages identified
• Every old URL mapped to a specific new URL, 301s ready to deploy

Cutover

• Staging import from real data
• Club billing test run and read line by line
• Compliance validated with live address tests
• Change freeze communicated internally
• Delta import completed
• Redirects deployed with the site, then verified by re-crawl
• First billing cycle actively monitored

Members

• Pre-change notice sent, framed around consequences
• Card re-entry campaign staffed, if required

None of this is glamorous and none of it shows up in the finished site. It is the difference between a migration your members never notice and one they remember for a year.

Migrations are included in the Winery DTC Sprint, and the free teardown that starts it will tell you whether moving is actually your highest-value next move. Sometimes it is not. If your club is losing members on the platform you already have, a migration relocates that problem rather than solving it, and the winery DTC playbook is the better place to start.