How do I prepare for an ERP implementation so it goes smoothly?

The difference between an ERP implementation that goes smoothly and one that drags usually comes down to preparation, and most of that preparation happens before kickoff.

It's the difference between signing a contract and actually being ready to start, and it's where the avoidable surprises live: the 3PL that needs ninety days' notice before it will change anything, half the ops team already being booked out on PTO, the Celigo contract renewing in six weeks, and TikTok Shop launching the same week you meant to cut over.

None of that is a software problem. It's a preparation problem, and the work you do up front can make or break the success of an on-time ERP implementation.

Here's what to line up before you start.

The Quick ERP Implementation Checklist

Work through this list before kickoff and write down an answer for each line. Then read on for the details behind each point.

You can download a PDF of the checklist to complete it, or copy it for your AI assistant from our ERP Implementation Checklist page.

• Systems vs process: Write down the three to five problems the ERP needs to solve, and move anything an SOP would fix onto a separate process list.
• Cross-team buy-in: Have each affected team (ecommerce, operations, finance, CX, wholesale) document its own challenges and what it needs solved.
• Timing: Choose a date or a specific window that avoids peak, marketplace launches, and big-box retail onboarding.
• Owner and team: Name one owner, a small core team, and a backup for each core team member.
• Calendars: Map holidays and PTO for the core team across the whole timeline, including the cutover week.
• 3PLs: Notify your 3PLs in writing, and open integration threads between them and your ERP vendor early.
• Contracts: List every contract on the order-to-cash path with its renewal and termination dates.
• What's next: List the next six to twelve months of planned change, and mark each item as day-one or later.
• Data: Clean and reconcile your SKUs, packs, costs, and locations before migration starts.
• Discovery: Get the scoping questions in advance, assign each section to the person who owns that area, and plan which workstreams can run in parallel.
• Dual-run and close: Budget time for dual-running and a slower first month-end close.

Decide whether it's a systems problem or a process problem

The first thing to get straight is whether you're looking at a systems problem or a process problem. An ERP fixes the first kind and does nothing for the second.

A systems problem is when the system of record is wrong, or when three systems are each pretending to be the one source of truth: Shopify, your 3PL portal, and a spreadsheet all reporting a different available-to-sell number, or nobody able to say with confidence which warehouse owns a given unit. Those trace back to a single question of which system is the source of truth. If you're still weighing what the software is really for, it's worth reading what an ERP should actually do for your DTC brand first.

Process problems are different, and no amount of software fixes them. If you have no SOPs, no owner for cycle counts, buyers who never look at inbound, or a CX team that refunds without checking a receipt, all of that is still there the day after you go live. So write the real failure down before you shop for anything. If the honest fix is "document how we receive" or "stop selling stock that's only incoming," do that first. Buying software to paper over a broken process just gives you a new user interface and the same issues you started with. The exercise that matters is getting ecommerce, operations, finance, and wholesale in a room and agreeing on the three to five challenges an ERP genuinely has to solve. If that list comes back empty, what you have is a process project, and it's cheaper to run that one first.

Get buy-in across every team

An ERP touches every team that touches an order, so the evaluation can't be run by one department in a vacuum. Before you get too far, get ecommerce, operations, finance, CX, and wholesale bought in, and ask each team to write down its own challenges in its own words: what's slow, what's manual, what breaks, what’s impossible today and what it actually needs help solving. That document does two things. It gives the ERP vendor a real picture of the work instead of one team's version of it, and it lets everyone in the room see the problems the other teams are living with.

That shared view matters more than it sounds, because the best solutions usually sit across the boundary between two teams rather than inside one. Take a return as an example. CX wants to issue the refund the moment the customer asks, finance wants it tied to what has actually been received, and the warehouse is the one that physically takes the unit back in. Decide the refund timing inside a CX silo and you've quietly created a reconciliation problem for finance and an inventory problem for the warehouse.

When each team has documented what it needs, those collisions surface during the evaluation, where they're cheap to resolve, instead of after go-live, where they're not. It's also how you find the requirements that only make sense once you can see two or three teams' problems at the same time.

Pick a time that can survive a cutover

Once the list is real, the next call is timing, and you want a window that can survive a cutover. Resist the instinct to "just move fast in Q4." Don't start during your peak, in the middle of a marketplace launch, or in the two weeks before a big-box onboarding, because those are exactly the moments when nobody has attention to spare. A good window is one in which each team within your organization has the time and energy to dedicate to implementation.

Be precise about what you're actually protecting, though. It's the cutover itself and the days on either side of it, when you want everyone focused and reachable. Most cutovers happen on a normal weekday rather than over a weekend, so the team is in and available if something needs a quick decision.

The preparation, on the other hand, can happen whenever. You can scope, train and configure right through a busy season, as long as you're not flipping the switch in the middle of peak. Give yourself enough runway after go-live to settle in before volume climbs, and you'll be in good shape.

Start with an owner, then build the team

When you're ready to get going, most teams stall on the same thing: not knowing where to start. So start with an owner. One named internal lead who can make decisions, not a committee and not "whoever has bandwidth that week." Around that person, build a small core team of ecommerce ops, finance, and a warehouse or 3PL liaison, each with a named backup so a single vacation can't stall you. Then pull the holiday and PTO calendars for that whole team across the implementation and the cutover. If your controller and your 3PL account manager are both out the week of go-live, that may cause problems. It's far easier to replan around PTO before you lock in a timeline with an ERP software provider than after.

The owner role is real work, not a title. In practice, they hand each part of scoping to the person who actually knows that area, then read every answer before it goes back to the ERP vendor. Be honest with the team about what this costs them, too: a typical Fulfil ERP implementation runs about twelve to fourteen weeks, and each core person should plan on roughly ten hours a week, more during scoping and the dry run. Get people into the system early, including seasonal staff and anyone joining mid-project, because the fluency they pick up in the first few weeks is what carries them through the cutover. And remember that holidays and heavy PTO don't just cost you the days people are out, they stretch the whole critical path. Map any long weekends, holidays, or team leave inside your window before you commit to a finish date, so the timeline reflects the calendar you actually have.

Tell your 3PLs early

Tell your 3PLs early, because a potential implementation is not something to keep quiet. They need real lead time to clean up the item master, test EDI or API connections, adjust ASN processes, run inventory in parallel, and cover the cutover.

Spring the project on them at contract signing, and you'll get an unwelcome surprise: a ninety-day change-notice requirement, a peak blackout, or a rate card that still assumes the old integration. Put the notice in writing, and use the conversation to ask two things: what they need from you (SKUs, pack hierarchy, unit of measure, label specs) and what they simply won't change mid-peak.

If you're moving or adding a 3PL as part of the project, know that the cutover has its own set of rules, and that you'll be reconciling their on-hand file every week until you trust the new one.

Don't wait for the integration conversation either. You don't need a contract signature to open a direct email thread between your ERP vendor and each 3PL, and it matters most for any system your vendor has no native connector to. Get the API docs in hand, keep yourself copied so it doesn't turn into a game of telephone, and give yourself the chance to catch anything strange in week one instead of at the dry run.

Audit every contract on the order-to-cash path

Review every contract that touches your order-to-cash or inventory path, not just the ERP you might be leaving. That means systems like SPS Commerce, Celigo, A2X, ShipStation-class tools, EDI VANs, and any iPaaS that maps Shopify to the warehouse. Note the renewal and termination window on each one, because a forced renewal three weeks into discovery can lock you into a connector you'd already planned to replace. Either renegotiate the terms of those agreements or time the project to reduce the amount of time paying for two full stacks at once.

The trap that comes up most often is an incumbent ERP that auto-renews on a fixed annual date, which is a good reason to land the migration just before that date rather than just after.

Review the next six to twelve months of planned change

Preparation isn't only about today's setup. It's also about where the business is going, so walk ecommerce, marketing, and sales through the next six to twelve months of planned change. New marketplaces like TikTok Shop, Amazon, or Faire. New Shopify Markets or a second storefront. Physical retail, BOPIS, or ship-from-store. New wholesale partners that need EDI, net terms, or allocation. Product launches that explode your SKU count or introduce lots and kits. Anything that genuinely has to be live on day one needs to be named before scoping, and just as important, anything that can wait should be allowed to wait. Treating a "maybe Nordstrom in spring" as a hard day-one requirement is one of the surest ways to watch a timeline slip. And if retail EDI is real for you, find out whether it routes through your own warehouse or a 3PL.

Clean the data before you map fields

Inventory and data hygiene belong in this phase too, not somewhere in the middle of the project. Get clear on which system is the warehouse source of truth today. Clean up your SKU masters, pack sizes, costs, and location lists before any migration starts. Cycle-count or reconcile the 3PL ahead of time so you're not loading a wrong opening balance into a brand-new system. And decide, in advance, what happens to open POs, open wholesale orders, and anything in transit at the moment of cutover. If you can't answer those questions yet, that's your sign that you're not ready to map fields.

Run discovery well, and run the workstreams in parallel

Of everything on this list, discovery moves the needle most on how fast and how well the rest goes. The scoping session itself is short, usually around ninety minutes and a hundred or so questions, but those answers feed straight into how the system gets configured, so they carry more weight than their length suggests. Ask the ERP vendor for the scoping question list in advance and pre-assign each section to the person who owns that area. That way, the session is spent reviewing considered answers rather than inventing them on the spot. Thin, rushed answers here come back as rework later, so get a real pass done in a week or two rather than letting it drift for a month.

It also helps to know the workstreams don't have to run one after another. Core configuration, data migration, finance, and EDI or trading-partner setup can all move in parallel, so while data migration is in flight, the EDI and channel work is already underway. Projects that run these tracks concurrently, each with a clear owner, finish noticeably sooner than ones that wait for discovery to fully close before anyone touches the 3PL.

Budget time for dual-run and the first close

Finally, give yourself real room for dual-running and for that first finance close. The first month-end on the new stack may be slower than usual as you learn a new system, so plan a soft-close rehearsal, and keep one person who still understands the old payout and COGS path until you close your books with the new system.

Don't feel that you need to turn everything on at once. Some brands are better off phasing the cutover: operations live first, finance shortly after, and the finance cutover aligned to the first of the month so you're not splitting a single period across two ledgers. Expect a dry run before go-live, then a week or two of daily calls afterward while the rough edges get found, before things settle into a normal cadence. If your old GL can still take a monthly export during the transition, keep that door open until the first clean close is behind you.

None of this is complicated on its own. A brand that shows up with a clear owner, a problem list that isn't really "SOPs would fix this," a 3PL that already knows what's coming, contract dates on a page, a realistic launch calendar, and a cutover window that respects everyone's PTO will fly through discovery and won't be rediscovering blockers later. Prepare well, and the implementation becomes easier.