Different pathways: Migration vs Maintenance

When software isn’t fitting the business anymore, you’ve got several pathways forward. The main pathways are to either improve your existing software, or replace it and migrate to something new.

There are pros and cons to each. The two options are distinct pathways. Let’s explore the distinctions.

Software Migration

Migrating from one software platform to another is a large-scale effort. You must:

• Select the best software platform to migrate to
• Move data and users from the old platform to the new platform
• Start using the new platform
• Eventually, sunset the old platform

The move from platform to platform is a significant change, and managing the cutover requires forethought.

Selecting a platform

To select a good platform to move to, you need to research the needs of all your platform’s users. Each job function will use the platform differently, and it’s important to consider all their uses. Then you have to research available platforms and select the one that meets current needs, has the potential to expand to support future capabilities, and has a vendor that will support it.

Doing this properly will take months of due diligence. It is difficult to find a platform that will meet your needs out of the box, so factor in additional development and customization to ensure the platform works with your processes.

Changing data and users

Once you have selected the platform and completed the initial setup, it’s time to move the data over. If you made your selection properly, you already have a migration path in place. If historical data is important, say for reporting, you need a plan to migrate it to the new system or to run reports from both the old and new systems at once.

You also need to train your users on the new system. This can be an unexpected lift for employees, who just want to get their job done and are often resistant to change. You are resistant to change, too. Just think about the last time your phone was updated. How happy were you to figure out where the buttons went? Plan for several months of moving data and retraining people.

Managing the cutover

There will come a point when you want to run on the new system fully. You’ll need to perform a cutover, pulling the most recent data from the old system into the new one, and moving to it. This is a step where many things can go wrong. It’s a good idea to practice the migration to minimize downtime, and to plan the timing so the disruption to employees, business, and production lines is minimal. There is always a disruption.

In short, there’s a lot of research, change management, and technical support required for the cutover. The Software Migration pathway is a large move. In software development, we’d call it a “Waterfall” approach, because it requires all the pieces to be in place at the same time. Let’s contrast that with maintaining and improving your current systems.

Software Maintenance

This pathway is more aligned with “Agile” methodologies and continuous improvement. Think of it as a highly focused process improvement. You take the components of the system that are the most painful and improve them one by one, in place. When there are points of pain within a system, it’s rarely the case that the entire system is broken and needs replacing. Rather, there are a few pain points that, if improved, could make a world of difference. The maintenance and improvement pathway zeroes in on that fact.

Instead of a huge shift from one system to another, with large capex, months of research, and the potential for disruption, this approach takes a much more focused look at what’s wrong and fixes it a little at a time. You can see that these two pathways can’t be compared apples to apples, since they differ so much in their approach. For a legacy software maintenance project, here are the steps for each improvement.

• Identify the point of pain.
• Devise a solution.
• Implement the solution in place.
• Repeat.

Identify the point of pain

If you’re considering a software migration, you already have points of pain in mind, so this is something you’ve probably already done. If not, just ask people what could make their job easier. What’s the worst thing about this system? Duplicate data entry, insufficient visibility for other team members, and a lack of audit capability are pain points we often hear from customers. The highlight of the Maintenance pathway is that you tackle one point of pain at a time. You don’t have to solve all the problems at once.

Devise a solution

Here’s the research step. Getting feedback from the people who touch this part of the process is much quicker than surveying everyone who will use the system (about all their use cases). In a few meetings, you can get people on the same page about the pain and what can be done to address it.

Implement the solution

Then you implement the solution. You’re only changing one part of the system, so the risk during deployment is lower. You don’t have to manage a huge cutover or data migration. Any change management is already handled by involving people in the solution, and since you’re taking things one bite at a time, it won’t overwhelm people with new things to figure out.

Repeat

Go back to the first step and pick the next point of pain to address.

The cycle time in this process is much shorter than a Software Migration. Within a few cycles, we find teams are much happier about the state of the system - the big points of pain are addressed, efficiency is increased, errors decreased, and you’re still months ahead of the timeline of a Software Migration.

The benefits

We’ve found that maintaining existing systems is a great alternative to a large-scale migration. Here are some of the benefits we’ve seen over the past decade:

• The cost is 10% to 25% of a Software Migration due to strong focus on pain points.
• You retain control over your processes rather than mirroring whatever the off-the-shelf software does.
• The timeline is much faster. It’s possible to roll out new changes weekly.
• You avoid the risk of large cutovers, change management, and figuring out how to handle historical data.

When you’re considering the next step for your business software, it’s worth looking at both pathways and weighing them against your goals.