Modernizing your systems without betting the business on one weekend

The projects that go badly wrong tend to share a shape. Everything gets replaced at once, over a weekend, after eight months of preparation, and on the Monday nobody can do their job. You have probably heard a version of this story from someone in your industry.

The alternative is less dramatic and considerably duller to describe, which is part of why it gets sold less often.

Find out what you actually run

Before anything else, build a list of every system the business depends on. Not the official list. The real one.

For each entry write down who uses it, what it costs a year, what it connects to, and what would happen tomorrow if it stopped. That last column is the useful one. It tends to reveal that the accounting package everybody complains about is far less critical than the unglamorous scheduling tool nobody has thought about in three years.

Two things usually surface during this exercise. Software you are still paying for that nobody has opened in months. And a spreadsheet, maintained by one person, that several important decisions quietly depend on.

Neither of those is unusual. Both are worth knowing before you start moving things.

Replace less than you think you need to

The instinct when systems are frustrating is to replace all of them. It is usually the wrong instinct, and it is expensive.

A lot of what feels broken is not the systems themselves. It is that they do not talk to each other, so people become the integration. Somebody exports from one, reformats it, and imports it into another, twice a week, forever. The frustration is real. The cause is the gap between the tools rather than the tools.

Connecting two systems you already own is dramatically cheaper than replacing either of them, and it does not require anybody to learn new software. Before agreeing to replace something, it is worth asking whether the actual complaint is about the tool or about what happens at its edges.

Sometimes the answer really is that the system has to go. Software that is no longer supported, or that cannot be extended, or that ties you to a supplier who has stopped caring, has a genuine end date. Just make sure you know which category you are in.

Sequencing, and why it decides the outcome

Assuming several things need to change, the order matters more than the individual choices.

Three principles are worth holding to.

• Each phase should deliver something useful by itself. If phase two is worthless without phase five, you have not sequenced the work, you have just divided a single risky project into instalments.
• Start where the pain is highest and the risk is lowest. That combination is usually somewhere in reporting or in an internal process, rather than in anything touching customers or money.
• Leave the system with the most connections until later. Whatever sits at the center of everything else is the one where mistakes propagate furthest, and by the time you reach it you will understand your own data much better.

A phase that takes six to ten weeks and produces something people can see tends to keep support alive. Anything longer than a quarter without a visible result starts to feel like money disappearing, and support is what you need when the difficult phase arrives.

Data migration is the part that overruns

It is worth saying plainly. Moving data between systems takes longer than anyone expects, every time, and it is where budgets go.

The reason is rarely technical. It is that twelve years of records contain twelve years of habits. Customer names entered four different ways. A field that meant one thing until 2021 and something else afterwards. Records with no owner, duplicates nobody noticed, addresses in a format the new system rejects.

Decide early how much history you are actually required to keep and how much you are keeping out of habit. Regulatory retention is a real constraint and usually shorter than people assume. Everything beyond that is a choice, and archiving old records somewhere searchable is far cheaper than migrating them into a live system where they will slow everything down.

Whatever the plan, run the migration twice before the real one. The first rehearsal finds the obvious problems. The second finds the ones the first rehearsal created.

The reason most of these projects fail

It is not the technology. It is that people carry on using the old way.

This happens for reasons that are entirely rational from where they sit. Training was one session, four weeks before launch, delivered by someone who already knew the system. The new process is slower for the first fortnight while everybody learns it. The person who understood the old way best was not consulted and is not enthusiastic. And there is no obvious place to ask a question at eleven on a Tuesday morning when something does not behave as expected.

Things that help, in rough order of usefulness. Involve the people who do the work while decisions are still open, not after. Train close to launch rather than months before. Write short guides for the ten things people do daily, in your own language rather than the vendor’s. Name somebody internally who owns the system and is allowed to spend time on it. And set the expectation openly that the first two weeks will be slower, so that being slower does not read as failure.

Knowing whether it worked

Decide the measure before you start, because afterwards everybody’s memory becomes flexible.

Useful measures are boring and specific. Days to close the month. Hours a week spent on manual entry. Number of systems a new employee needs access to on day one. How long it takes to answer a question a customer asks.

Record those now. Record them again ninety days after each phase. It is the only way to know whether the thing you spent money on changed anything, and it is far more convincing than anybody’s impression at the end of a long project.