Managed Migrations Overview

Migrating your subscription program to Ordergroove is a big move, and one of the most consequential business decisions your team will make this year. Done well, it sets your program up to grow. Done without preparation, it can quietly reshape what your reporting looks like on day one.

This guide walks you through what a migration actually involves, what you need to bring to the table, what Ordergroove handles for you, and the decisions you'll need to make along the way.

Launching subscriptions for the first time? If you don't have an existing program, you don't have a migration to plan — you have a launch. Your Solutions Partner will guide you straight to program setup, and you can skip this article.

What a managed migration actually is

A migration is the process of moving your existing subscribers, their subscriptions, and the data that supports them (addresses, payment tokens, pricing rules) from your current platform onto Ordergroove.

We call ours a managed migration because we lead the technical work. You provide your subscriber data in a structured format. We handle data transformation, validation, test runs, error remediation, and the final import. You don't need to run our tooling, interpret error logs, or fight with file formatting — but you do still need to make the business decisions that shape what your program looks like on the other side. There will be several.

Ordergroove can ingest:

• JSON or JSONL
• CSV
• XML
• Direct API access for Recharge and Skio (no file needed — we pull the data ourselves once you authorize the connection)

The format isn't the important question. What's inside the data, what's missing from it, and what decisions you'll need to make about both — that's most of what this article is about.

What "managed" doesn't mean

Managed doesn't mean "hand us the keys and we'll see you at launch." A migration is a partnership. We do the technical lifting, but you own the business decisions, and there will be several. The sections below walk through what those are and when they come up.

The shape of a migration: pre, during, post

Every migration runs in three phases. Most of the work — and most of the decisions that matter — happen in the first phase, before any data moves.

A typical migration takes about a week of active work once we begin, though larger or more complex programs may take longer (see Factors that influence migration speed below). Preparation usually takes longer than the migration itself — weeks, sometimes months, depending on the state of your data. We'll get into why in the next section.

Pre-migration: what to bring, what to decide

This is where merchants most often get caught off guard. The reason is consistent: teams treat migration as a technical event that happens later, when really it's a business event that's already happening now. The decisions you make here shape what your program looks like on launch day.

Your shopping list

Here's what Ordergroove needs to perform your migration. Some of it lives in your current subscription platform. Some lives in your ecommerce platform. Some lives in your payment gateway.

1. Customer data. Names, email addresses, and the basic profile your ecommerce platform requires (which may include phone numbers, full addresses, and other fields depending on the platform).
2. Subscription data. The active subscriptions themselves: what products, what cadence, what next order date, what status.
3. Shipping and billing addresses. Per customer, in the format your destination ecommerce platform expects.
4. Payment data. The tokens that let us charge your customers on a recurring basis. This is where the trickiest constraints live — more on that below.
5. Anything complex or custom about your program. Prepaid subscriptions, bundles, rotating clubs, locked pricing, custom discount logic, membership tiers, complex incentive structures. Flag these early. Complex order calculations slow down every part of the migration, so the sooner we know, the better we can plan.

Your Solutions Partner will give you the platform-specific field requirements for your destination ecommerce platform and payment gateway. Different platforms require different things. Shopify, Salesforce Commerce Cloud, BigCommerce, and custom builds each have their own rules, and even when fields overlap, the format expectations differ.

For a closer look at what the file structure looks like, see our migration file example. If you're providing data via Recharge or Skio API access, we'll handle the format on our side — you just authorize the connection.

Decisions you'll need to make

A migration forces decisions that may not have come up during sales. Make them early. Leaving them for implementation is where timelines slip.

How will you handle subscribers with incomplete data? This is the single most common cause of migration friction. If 30% of your customers are missing phone numbers and your destination platform requires them, you have two options: run a campaign to collect the missing data before migration, or accept that those subscribers won't migrate. Both are valid choices.

Will you migrate everyone at once, or in stages? A staged migration — moving discrete groups of customers over the course of days or weeks — can reduce risk and limit customer-facing impact. It also requires the technical capacity to run your old and new systems in parallel, which not every merchant has. If staged migration is something you're considering, talk to your Solutions Partner early about whether it's feasible for your setup.

Who on your team owns the migration? A migration needs more than one named owner. The ideal setup is a business counterpart (an ecommerce manager or project manager who can make calls about timing, customer impact, and data tradeoffs) paired with a technical counterpart (someone who can speak to your existing data, your platform configuration, and downstream integrations). Either alone tends to stall — the business person waits for technical input, or the technical person waits for business approval. Name both up front.

Decisions you’ll need to make

These come up in nearly every migration. Naming them up front is the easiest way to avoid surprises later.

Active vs. inactive subscriptions. Ordergroove defines an active subscription as one with a future order date. If your current platform defines "active" differently — for example, including subscriptions that are paused or between orders — your active subscriber count will shift the moment migration completes.

Separately: subscriptions imported without a valid payment method will be active in the data but can't actually be charged when their next order comes due. We'll flag these during validation so you can decide how to handle them.

Primary keys may change. If you're moving ecommerce platforms as part of this migration — say, from Salesforce Commerce Cloud to Shopify — your customer IDs, product IDs, and order IDs will change. Some platforms let you keep your existing IDs; others (Shopify is the clearest example) assign new ones and don't give you the choice. These IDs typically connect to other systems on your side: ERP integrations, business intelligence tools, cohort reporting, downstream automations. We'll work with you to map old IDs to new ones, but you'll need to be the one to flag what's connected downstream and what will need updating.

Wallet payment tokens can't be migrated. Apple Pay, Google Pay, Shop Pay, Venmo, and other wallet-based payment methods can't be extracted and ported between platforms in most cases. That's a constraint of the payment industry, not of Ordergroove. Subscribers paying through wallets will likely need to re-enter a payment method, or they won't migrate. If a meaningful share of your subscribers pay this way, plan for it — usually a customer outreach campaign before migration, sometimes a winback campaign after. Your Solutions Partner will confirm what applies to your specific setup.

One-time items don't come over. Ordergroove supports adding one-time items to subscription orders, but the migration doesn't bring over existing one-time items from your previous platform. If your customers have one-times queued up for their next order, tell your migration team early so you can plan how to handle them.

Discounts get rebuilt, not migrated. Discounts on Ordergroove are recreated as Offer IDs, and migrated subscriptions are assigned to the relevant offer. Unique per-subscriber discounts and locked pricing need to be included in the initial data export — adding them in a second wave is possible, but it adds time and scope.

Bad data causes more errors than anything else. Missing or improperly formatted phone numbers, address lines, postal codes, and similar fields cause more migration errors than any other category, full stop. The fields and formats your destination platform requires may not have been required on your previous platform. Your Solutions Partner will share the exact list early; treat it like a checklist.

How Ordergroove handles some things

A few things about how Ordergroove is structured will affect how your data maps over. Worth knowing in advance.

Payment tokens are tied to individual subscriptions. Ordergroove supports tying a payment token to each subscription, which gives your customers the flexibility to pay for different subscriptions with different cards if they choose. Many merchants opt to use a single default payment method per customer instead — both work. The flexibility is there if you want it.

Pricing is dynamic by default. Ordergroove pulls the current product price from your catalog and applies the appropriate discount through the Offer ID. You can lock a price per subscription if you need to, but doing so limits flexibility — features like SKU swap become harder. Most merchants are better off with dynamic pricing.

Ordergroove relies on your ecommerce platform for billing. We send the order with the payment token to your ecommerce platform, and your platform's payment processor charges the card. This means recurring orders need to be tested thoroughly during implementation. Migration validates that data moved correctly, but only test orders confirm that money will actually move on launch day.

Reporting and the new baseline

Most migrations involve a small shift in how your program looks on paper. This isn't an error and it isn't a problem with Ordergroove — it's a consequence of moving between platforms with different definitions of "active," different requirements for valid data, and different calculation logic for the same-named metrics.

Before migration begins, do this:

• Capture your current baseline. Total subscribers, active subscriptions, average order value, recurring revenue. Whatever you report on, write the numbers down now.
• Expect those numbers to change on day one of launch, and not always in the direction you'd predict.
• Talk with your Customer Success Manager (CSM) about which of your existing reports will translate directly and which will need to be rebuilt or redefined.

This is one of the most important pre-migration conversations to have, and one of the most frequently skipped. Your CSM can walk you through the specifics for your program.

What to do in your ecommerce platform before migration

A few platform-side configuration items need to be in place before we begin:

• Test subscriptions. Create 1–3 staff subscriptions in your current program, tied to real employees of your company. We'll use these to run a live end-to-end test before touching any real subscriber data.
• Payment gateway. Confirm with your Solutions Partner that your payment gateway is configured to accept tokenized recurring payments from Ordergroove.
• Checkout settings. Fields that aren't present in your migration data need to be optional or disabled at checkout, or your test orders will fail. The usual suspects: shipping phone number, address line 2, company name.

Your Solutions Partner will give you the full checklist for your specific platform and gateway combination.

⚠️ Important: data is locked from the moment migration begins

Once we start your migration — from the moment the first data file is created or extracted — your subscriber data is effectively frozen. The migration tool can only insert new records; it can't update existing ones or accept incremental changes. This means no subscription edits, no customer-initiated changes, and no preloading. Once the freeze begins, it stays in place until the migration is complete.

Plan for the freeze, communicate it to your customers in advance (see below), and time it carefully.

Customer communication

Give subscribers a heads-up before migration begins. Let them know:

• Subscription management will be temporarily unavailable during a defined window
• Recurring orders may be briefly paused
• They should make any changes to upcoming orders before the window begins, because changes during migration aren't possible

A short follow-up letting them know the system is back, once migration is complete, is a nice touch — and a good chance to mention any new features they'll now have access to.

During migration: what we do, what you do

Once your data is ready and your store is prepared, the active migration begins. This is the phase where Ordergroove is doing most of the work, but you're still on the hook for a few key decisions.

What Ordergroove does

• Extracts data from your existing platform, or ingests the file you provide
• Transforms the data into the format our systems need
• Runs validation passes to catch missing or malformed data before it touches production
• Performs a canary migration with your test subscriptions
• Places test orders against those test subscriptions
• Identifies errors, works with your team on data gaps, and re-runs imports as needed
• Imports your full subscriber base
• Monitors the first wave of recurring orders post-launch

What you do

• Provide the data, or API access
• Freeze activity on your old system at the agreed-upon time, and keep it frozen until we're done
• Review the canary migration results and approve moving forward
• Make decisions on any data gaps we surface during validation (some of these are business decisions, not technical ones — see below)
• Approve the modified baseline numbers if they've shifted from what was originally scoped

Factors that influence migration speed

A typical migration runs about a week of active work. Yours might run faster, or it might run longer. Every migration has its own personality. The biggest factors:

• Your destination platform. Some platforms — Shopify in particular — require additional steps on our end that other platforms don't. This can meaningfully extend the timeline. Your migration team will give you a realistic estimate based on your specific setup.
• The size of your program. A migration of 5,000 subscribers and a migration of 500,000 don't take the same amount of time, even if everything else is identical.
• The complexity of your program. Bundles, multi-tier incentives, prepaid programs, custom discount logic, and similar features make each record more expensive to process. The more sophisticated your program, the longer the migration.
• Data quality. Clean data flies through. Data with lots of missing or malformed fields means more error remediation, which means more time.
• Whether you're changing platforms at the same time. If you're moving to a new ecommerce platform alongside the migration to Ordergroove, primary keys and IDs are also changing — see Data realities above.

This isn't a comprehensive list. Every migration surfaces its own quirks. Use this to set expectations, not to predict an exact timeline.

A typical week-long timeline

Many migrations fit comfortably into a five-day window, with buffer for the unexpected. Larger or more complex programs may take longer.

Staged migrations span more calendar time by design. Your migration team will share the timeline tailored to your program at least 30 days before migration begins — and we ask that you confirm it then. We know launch dates sometimes shift; tell us early when they do.

When we're available

Migration day starts early, our direct support window is 9am–6pm ET, Monday through Friday. During those hours you'll have:

• Real-time updates as data processes
• Active error remediation
• Live monitoring during the first wave of order placements
• A direct line to the migration team for anything urgent

We'll work outside that window when it's necessary, but the bulk of our active engagement is during business hours. Plan your customer-facing communications and internal stakeholder check-ins around that.

Why test subscriptions matter

The test subscriptions you created in pre-migration do a lot of work here. They confirm:

• Your data imported into Ordergroove correctly
• Stored payment tokens work
• Recurring orders flow through to your ecommerce platform
• Your fulfillment system picks up the order normally

If something is going to break, we want it to break on a test subscription belonging to one of your employees — not on your highest-LTV subscriber. That's why the Day 1 canary is non-negotiable.

When errors come up

Some errors are easy fixes — a malformed address, a missing field we can backfill from another source. Others surface deeper issues that need a decision from your team. A few things to know:

• Some errors aren't technical problems; they're business decisions. If a subscriber is missing data we can't infer, we'll need you to decide how to handle them: collect the missing data, migrate them without it (if the platform allows), or leave them behind for a winback campaign. We won't make those calls for you.
• Re-running imports doesn't create duplicates. The migration process is idempotent. If we fix a data issue and re-run, the same subscribers don't get imported twice.
• We can pause order placement if needed. If a systemic issue surfaces during the first wave of recurring orders, we can stop the queue while we resolve it.
• Some errors won't be resolvable. A subscriber missing data we can't update, or paying through a wallet token we can't migrate, won't make it through. For these, we'll help you plan a winback campaign post-launch.

Post-migration: confirming, resuming, adjusting

Migration day ends, but the migration isn't really done until the first full cycle of recurring orders has run cleanly. This phase is short, but what you do here shapes how launch lands for your subscribers and your team.

Confirming the migration succeeded

In the days right after migration, your migration team will work with you to confirm:

• Subscribers can log in and see their subscriptions
• Subscription management actions (skip, swap, pause, cancel) work as expected
• The next wave of recurring orders processes successfully
• Payments are captured and reconciled with your payment processor

This is also when you'll want to check against the baseline you captured pre-migration. Some shifts are expected. Large unexpected ones are worth flagging immediately.

Resuming customer activity

During migration, customer-facing subscription management is typically disabled to prevent data inconsistencies. Once we've confirmed orders are processing cleanly, that gets re-enabled.

If you communicated with subscribers before migration, this is when you let them know everything is back to normal.

Winback campaigns

If a portion of your subscribers couldn't be migrated — usually because of wallet payment methods or data gaps that couldn't be filled in time — your migration team will help you plan a winback campaign. These are typically email-based, ask the subscriber to re-enter payment or update their profile, and re-enroll them in their subscription on Ordergroove directly.

Recovery rates vary by category, list quality, and the cause of the original failure. Your CSM and migration team can give you a realistic read on what to expect.

Adjusting your reporting

The reporting conversation that started in pre-migration finishes here. Within the first two weeks post-launch, you and your CSM should:

• Compare your pre-migration baseline to your post-launch numbers
• Identify which reports translate cleanly and which need rebuilding
• Set expectations internally for the first quarter's metrics

The deeper guide we mentioned earlier will go further on this. For now, the most important step is just knowing the conversation needs to happen — and putting it on the calendar instead of stumbling into it at the next QBR.

When to start preparing

As soon as you sign. The most valuable thing your team can do is start surfacing the data realities that'll shape your migration window.

The early-and-cheap work:

• Audit your current subscriber data for missing required fields. Phone numbers and addresses are the usual suspects.
• Identify what payment methods your subscribers are using — in particular, what percentage pay via wallet methods.
• Catalog any custom pricing, bundles, prepaid programs, rotating clubs, or membership tiers that need special handling.
• Map your downstream integrations. If your customer IDs or product IDs are going to change as part of this migration, you'll need to know what connects to them.
• Name both your business owner and your technical counterpart for the migration.

None of this requires Ordergroove. All of it shortens your migration timeline and reduces the risk of surprises later.

When your Solutions Partner reaches out to start the migration conversation in earnest, you'll be ready.

Working with the Ordergroove team

A few practical things about how we work:

• You'll have several named contacts. Your Solutions Partner leads the data preparation, platform configuration, and migration execution. Your CSM owns the ongoing relationship and is your point of contact for reporting, baseline reconciliation, and post-launch strategy. Your migration team runs the active work during the migration itself.
• We work during business hours (9am–6pm ET). Migration day starts earlier when needed, but error remediation and active monitoring happen during these hours.
• We don't surprise you. If something material changes — a timeline shift, a new data issue, a baseline that's moved more than expected — you'll hear it from us before you hear it anywhere else.
• We expect the same. If your launch date moves, a stakeholder changes, or you discover a data issue, tell us early. The 30-day timeline confirmation isn't bureaucracy — it's when we lock resources for your migration window.

What's next

Your Solutions Partner will be your guide through the specifics. This article is the map; they'll walk the territory with you.

If you're early in the process and want to start preparing your team, focus on the pre-migration sections above. If you're already in active migration, the during-migration section is your reference. And if you're post-launch and trying to make sense of your reporting baseline, that conversation is the most important one to schedule next.

For the data file structure itself, see the JSON-L example. For platform-specific field requirements and format details, your Solutions Partner will share what applies to your specific setup.