An ERP implementation is one of the largest projects a retailer takes on. Panorama Consulting’s recent surveys put the median ERP project at 9 to 15.5 months, and large multi-entity programs often run longer. One department store retailer we spoke with was 18 months into an SAP S/4HANA implementation and still planning for go-live.

Those projects consume IT capacity, executive attention, and budget, so it makes sense that many planning leaders hear the same advice from inside the building: hold off on anything else until the new system is live.

Sometimes that’s the right call. Often it isn’t, because the merchandise calendar keeps moving. During a two-year migration, a planning team will build several seasons of buys, set open-to-buy, allocate launches, and react in-season, all with whatever tools it had when the project started.

Why Brands and Retailers Delay Planning Software During an ERP Implementation

The instinct to wait usually comes from three reasonable concerns:

• IT bandwidth. The people who would support a planning integration are the same people running the migration.
• Building on a moving target. If the item master, location hierarchy, or transaction tables are changing, integrating now could mean integrating twice.
• Risk containment. Leadership doesn’t want two major system changes at the same time.

These are all valid concerns. The trouble is that they’re usually framed as if planning were a module of the ERP project. With most brands and retailers, it isn’t. Planning decisions run on their own calendar, and that calendar doesn’t pause for a go-live date.

What Waiting Costs the Planning Team

Even a typical ERP project can span four buying seasons, and timelines slip. In Panorama Consulting’s 2026 survey, about one in five organizations finished late, and data issues were a cause in more than a third of those delays.

Each of those seasons gets planned with the existing process, which for many mid-market brands and retailers means spreadsheets, manual allocation, and forecasts rebuilt by hand each week.

The cost goes beyond inefficiency. During long migrations, three things tend to happen:

1. Workarounds Become Permanent

The temporary spreadsheet built to cover a data gap during the transition becomes the system of record for planning.

2. The ERP Absorbs Planning Requirements It Wasn’t Designed For

Planners ask the ERP team for custom fields, allocation rules, and reports. Each request adds scope to an already large project.

3. The Planning Team Arrives at Go-Live With The Same Process It Had Before

A new ERP improves transactions, inventory accuracy, and financial controls. It doesn’t change how the team forecasts, allocates, or builds an assortment.

When Waiting For ERP Go-Live Is the Right Call

Waiting can be the better choice when:

• There’s no stable source of sales, inventory, or product data, in either the legacy system or the new one, for the next several months.
• IT can’t spare any time for data mapping, even a few weeks. Any planning implementation needs someone to map data feeds, whatever the vendor promises.
• The planning team itself is being restructured and doesn’t yet have clear owners for the process.

If none of these apply, the decision shifts from “wait or not” to “how do we add planning without adding risk to the migration.”

Three Common Traps When Planning During an ERP Migration

1. Customizing the New ERP To Handle Planning Flexibility

ERP allocation and reservation logic is built for transactional accuracy, not for in-season judgment. When teams try to recreate store-to-store redistribution, constraint-based allocation, or strategy-specific safety stock inside the ERP, they lock in rules before they know what post-go-live performance looks like. Those customizations are also expensive to maintain through every future ERP upgrade.

2. Running Heavy Planning Calculations Inside the ERP

Allocation and forecasting are iterative. They recalculate across every SKU, size, and location, often every night. Running that work inside a transactional system can strain capacity. One specialty retailer we spoke with was told its ERP tier was already at capacity, and that adding a new integration could mean a six-figure annual upgrade. Whatever the exact number turns out to be, where the heavy calculation runs is an architecture question to settle early, not after go-live.

3. Tying Forecast Improvements to the Cutover Date

Better demand forecasting depends on clean sales history and a consistent product hierarchy. It doesn’t depend on which ERP produced them. Teams that link forecasting upgrades to go-live often delay a forecast improvement by a year or more, even though the history they need already exists.

How a Merchandise Planning Layer Works Across Legacy and New ERP Systems

The alternative is to treat planning as its own layer. It sits above the ERP, reads data in, and writes decisions back out. Done well, that layer can operate on the legacy system, through the transition period, and on the target ERP, without a core-system cutover of its own.

Here’s how that works in Toolio:

• Each data feed can come from a different system. Sales might come from the legacy ERP while product data comes from the new one, or from a data warehouse sitting between them. Running two systems side by side during a migration is a supported setup.
• Planning logic runs in Toolio, not the ERP. Allocation runs nightly inside Toolio, using size and location curves. When stock is constrained, planners choose between Demand First and Minimum Presentation First. Optional features like Location Capacity, which caps transfers to each store, and Redistribution, which moves excess SKU by SKU to locations facing shortfalls within defined groups, are configured in Toolio rather than built as ERP customizations.
• Receipt and PO planning respects real constraints. Lead times, minimum order quantities, and case packs are built into open-to-buy and receipt planning. Weeks-of-supply targets can be set at the org or variant level.
• Decisions go back to the ERP as standard transactions. Toolio integrates purchase orders and transfer orders directly. The system can receive them through native write-back, S3, Google Cloud Storage, Azure, SFTP, or CSV. Toolio doesn’t orchestrate fulfillment. The ERP stays the transactional system of record.
• Forecasting can improve now. Toolio’s AI forecast model retrains weekly on at least a year of history, with retrending applied as a separate step during forecast runs.

When the new ERP goes live, the planning workflow stays the same. Importers and exporters get repointed to the new system with Toolio’s team. That’s real work to plan for, but it’s a remapping exercise, instead of a second implementation.

Questions IT Teams Ask About Adding Planning Software Mid-Migration

Does This Add Load to the ERP?

The heavy calculation runs outside it. The ERP’s role is to supply data and receive exported POs and TOs.

What Happens at Cutover?

Data feeds are repointed from the legacy source to the new one. Planners keep working in the same plans, with the same history.

What if Our New ERP Doesn’t Have a Native Connector?

Many brands and retailers already route data through a warehouse like Snowflake, BigQuery, or Redshift, or through SFTP and automated CSV. That’s a common pattern for D365 environments and others without a direct connector.

What Do We Wave to Regression Test?

Because the planning layer doesn’t change ERP code, the ERP-side surface is limited to the inbound PO and TO files or API calls. That’s a much smaller footprint than custom planning logic inside the ERP.

Evaluating Planning Software During an ERP Implementation

For Planning Leaders

• What does that cost the company from a revenue and margin standpoint?
• Which planning requirements are we currently asking the ERP team to build?
• Can the planning tool run on our legacy data now and switch to the new ERP’s data later without rebuilding plans?
• Can allocation handle in-season redistribution and store capacity limits without ERP customization?

For IT Leaders

• Where do the allocation and forecasting calculations run?
• Which systems can each data feed come from, and can feeds come from different systems at the same time?
• What does the vendor’s team do at cutover, and what does ours do?
• How are POs and TOs delivered back to our ERP, and is that native or file-based?
• What ERP-side changes, if any, does the integration require?

Should You Wait For ERP Go-Live to Modernize Planning?

An ERP migration is a good reason to be careful about planning software. It isn’t automatically a reason to wait. The real question is whether planning can sit beside the migration without depending on its timeline. If it can, the team gets several seasons of better decisions and arrives at go-live with a process that’s already working.