Replatforming decisions almost always get made at the worst possible moment, and there is a structural reason why. The conversation about replacing a core system rarely starts because someone calmly concluded, in a quiet quarter, that the time had come. It starts because the pain got loud. A bad close, a failed audit, a growth push the current system could not support, a breakdown that made the limitations undeniable. The pain reaches a threshold, the organization decides it has had enough, and the mandate comes down: fix this, now.

That trigger feels like decisiveness. It is actually a trap, because the moment the pain peaks is, with remarkable reliability, the moment your organization is least equipped to execute the fix well. The conditions that make a replatform succeed and the conditions that make the pain unbearable tend to occur in opposite phases. So "now, because it hurts now" is not the responsible answer it feels like. It is the timing most likely to turn a justified replatform into a failed one, and learning to resist it is one of the more counterintuitive disciplines a leader can develop.

The paradox of the trigger

Consider what a replatform actually needs from an organization to go well. It needs slack, spare capacity in the very people who run the operation, because they will be pulled into design, testing, data validation, and training on top of their day jobs. It needs stability, a business that is not simultaneously fighting other fires, so the transition has the organization's attention. It needs clean, reconciled data, because migrating a mess produces a mess. And it needs an off-peak window, a stretch where a temporary dip in performance during the learning curve will not coincide with the busiest, highest-stakes period of the year.

Now consider when the pain of an old system peaks. It peaks when the business is growing fast and the system cannot keep up, which is exactly when there is no slack. It peaks during a crisis or a scramble, which is exactly when there is no stability. It peaks at close, at audit, at the height of the season, which is exactly when the data is most in flux and the calendar has no safe window. The pain and the readiness are inversely correlated. The louder the system screams that it must be replaced, the less able the organization is to replace it well. This is the paradox at the center of replatforming timing, and most companies walk straight into it, because the pain is what starts the conversation and the pain is precisely the wrong signal to act on immediately.

Hershey learned this the hard way

The most instructive case in enterprise systems is not a story about the wrong technology. It is a story about the wrong time. In 1999, Hershey went live with a major new ERP system in July, heading directly into the ramp for its two biggest sales periods, Halloween and Christmas. The decision to modernize was defensible. The timing was catastrophic. With systems barely stabilized and staff still climbing the learning curve, the company hit peak demand at its lowest point of readiness. The result was roughly $100 million in orders it could not process, a reported quarterly profit drop of around 19%, and an annual sales decline near 12%, with product sitting in the warehouse that the systems could not get out the door.

The lesson that gets drawn from Hershey is usually about testing, and testing did matter. But the deeper lesson is about the window. Even a better-tested version of that project would have been fighting a strong current, because it went live into the one period of the year when there was no room for the temporary performance dip that even well-run implementations produce. They chose the moment of highest stakes and lowest slack to attempt the transition, and the calendar did the rest. The failure was not that they modernized. It was when.

The readiness window is a real thing, and it moves

If the wrong time is when the pain peaks, the right time is defined by readiness, and readiness is not constant. It comes and goes. There are periods when the business is stable, the team has capacity, the data is in reasonable shape, and the calendar offers a genuine off-peak stretch long enough to absorb a transition and stabilize before the next peak. Those windows are when a replatform has the best chance of succeeding, and they frequently do not coincide with when the system's limitations are loudest. Often the right window is earlier, before the pain became acute, when a leader saw the constraint coming and acted while there was still slack to act with. Sometimes it is later, after the immediate crisis has passed and the organization has recovered the capacity to take on a major change.

The discipline this asks for is to decouple the decision that a replatform is warranted from the decision of when to begin it. Those are two separate judgments, and collapsing them is the error. You can conclude that the current system genuinely must be replaced and also conclude that the right moment to start is not this quarter but the one after the busy season, when the conditions for success will actually be present. Recognizing that a replatform is needed does not obligate you to begin it at the moment of recognition, which is usually the moment of maximum pain and minimum readiness.

The honest line: you can also wait too long

This argument has an obvious failure mode, and it must be named, because "the timing is never quite right" is the oldest excuse for never acting at all. Readiness-based timing can curdle into permanent deferral, where every quarter has a reason it is not the moment, the window never seems to arrive, and the genuinely necessary replatform gets postponed until the system's limitations do real, compounding damage. That is not discipline. It is avoidance wearing discipline's clothes, and it is just as costly as lurching at the wrong moment.

Two things keep readiness-based timing honest. First, the recognition that switching costs and the damage of an inadequate system both compound over time, so waiting is never free and a decision deferred too long becomes a worse decision. The window is not "whenever it is perfectly convenient," because it never will be. Second, and more important, is the recognition that the right window does not always arrive on its own, and when it does not, a leader has to create it. Deliberately clearing capacity, stabilizing the business, cleaning the data, and protecting an off-peak stretch is often the actual work of good timing, rather than waiting for a naturally quiet period that a growing company may never get. The goal is not to wait for readiness to appear. It is to either find the window or manufacture it, and then move with conviction inside it.

Choose the window, do not lurch at it

The practical discipline reduces to a sequence most companies invert. First, decide on the merits whether the system genuinely needs replacing, using a real assessment of cost rather than the volume of the current pain, the question at the heart of the case against ripping out your systems. Then, separately, identify or create the window in which the organization can actually execute it well: stable, resourced, with clean data and a protected off-peak runway. Only then set the pace, matched to what the organization can absorb, which is its own distinct discipline. And throughout, hold the standard of good enough rather than perfect, so the project has a defined finish, the point made in when good enough is the right call.

The instinct to fix a painful system immediately is human and it is almost always wrong. The best time to replatform is rarely the moment you most want to, because that moment is defined by pain, and pain is the enemy of the readiness a successful transition requires. The leaders who replatform well are the ones who separate the decision from the timing, refuse to let the loudest pain set the schedule, and either find or build the window in which the change can actually succeed. Deciding to change is the easy part. Choosing when is where the judgment lives.

FAQs

Q1. If our system is causing real pain now, why shouldn't we replace it now?
Because the pain peaking and your ability to execute a replacement well tend to occur in opposite phases. When a system hurts most, the business is usually growing fast, firefighting, or at peak season, which is exactly when you have the least slack, stability, and calendar room to run a transition. Acting at that moment often converts a justified replatform into a failed one.

Q2. Isn't separating the decision from the timing just a way to procrastinate?
It can be abused that way, which is the real risk. The safeguard is to recognize that waiting is never free, since both switching costs and the damage from an inadequate system compound, and that the right window often has to be created rather than waited for. Separating decision from timing is discipline only if it leads to a deliberate window, not to indefinite deferral.

Q3. What actually makes a good window to replatform?
Organizational slack in the people who run operations, a stable business not consumed by other crises, clean and reconciled data to migrate, and a genuine off-peak stretch long enough to absorb a transition and stabilize before the next peak. When those conditions are present, a replatform has its best odds. They frequently do not coincide with when the system's limitations feel most urgent.

Q4. What does the Hershey case really teach?
That timing can sink even a defensible modernization. Hershey went live heading into its biggest sales season, hitting peak demand at its lowest readiness, and suffered roughly $100 million in unprocessed orders and steep profit and sales declines. The usual lesson drawn is about testing, but the deeper one is about the window: they attempted the transition at the moment of highest stakes and least slack.

Q5. What if a naturally quiet period never comes for our business?
Then part of the job is to create the window rather than wait for it: deliberately clearing capacity, stabilizing operations, cleaning data, and protecting an off-peak runway. Fast-growing companies in particular may never get a naturally quiet stretch, so manufacturing the conditions for success becomes the actual work of good timing, rather than an excuse to keep postponing.

Q6. How do we avoid waiting too long?
Hold two facts in view: the cost of an inadequate system compounds while you wait, and the perfect moment will never arrive on its own. Set an honest deadline for either finding or creating the window, and treat repeated "not yet" answers as a warning sign of avoidance rather than prudence. Readiness-based timing is meant to improve the odds of success, not to justify never starting.

Q7. Should the pain of the current system factor into the decision at all?
Into the decision of whether to replace, yes, but as evidence to be quantified rather than as a trigger to act immediately. Pain signals that something may be wrong and worth assessing. What it should not do is set the schedule, because the intensity of the pain is not correlated with the organization's readiness to execute a fix, and often runs opposite to it.

Q8. Who should own the timing decision?
Leadership, and it should be made deliberately rather than defaulting to whenever the pain forced the conversation or whenever a vendor is ready to start. The timing of a major transition is a judgment about the organization's readiness and calendar, which sits with the executives accountable for the outcome, not with the urgency of the moment or an external schedule.