Smart strategies for system upgrades

Piloting the solution by rolling it out to a smaller segment of users is often part of the launch of a new system, where the impact of a new version or platform is reduced. Of course, the extensive testing pre-pilot should largely solve any major issues. The pilot period might surface things like performance limitations under certain loads (that the project team would then look to rectify before complete roll out).

It’s also a great cost-saving measure - a controlled pilot that catches issues will be much cheaper and faster to rectify during the project before launch. Many projects will run pilot testing quite early on in the piece - continually refining the product as it’s stress tested.

Yes, some events are unavoidable, but it’s often those that are totally unexpected and blindside the team that leave the biggest impact. Common risks during a systems upgrade include integration failures, cost blowout and even issues with user adoption. By spending time to identify and mitigate these risks, your system's upgrade has a reduced chance of falling off the tracks.

For large organisations with operations that depend heavily on a certain system that’s been upgraded, it might be preferable to continue running both. That might mean short term double-handling and inefficiency, but it offers a fall-back should the new platform run into issues.

Good communication over an upgrade doesn’t just mean giving a heads-up email before the switch. Ideally the business will be given plenty of advance notice in order to prepare and work around this if need be.

Comms should also aim to provide context into the ‘why’ of a system upgrade. This can help explain any rocky patches in the early roll out and create a more patient user base. Remember, most users just care about how it will affect them - whether that’s your customers or staff. With adequate context setting, you should find there’s fewer grumpy emails and calls, and perhaps even some advocates across the business to help onboard others into the new system.

For some enterprise tech stacks, certain features of a system can be used while others are rolled out later. This can also apply to updating multiple systems. Piece-by-piece is not only a lower risk strategy in many respects, but it can be useful to gradually onboard a business to new platforms and ways of working.

On the other hand, a ‘microservices’ approach means that the business combines many smaller services and applications to power its operations. Each will function independently with its own codebase and often teams to support them. They will talk to each other via APIs. This approach may be more ‘complex’ on the surface, but it actually enables more agility to upgrade certain systems without major outages.

To the end user, microservices may work together into one front end experience, but behind the scenes they’re managed separately, creating more resilience to outages or issues.

This could be other platforms but it could also be the end of the financial year, big changes in personnel, during mergers or acquisitions or periods of the year that are peak customer engagement times. What these activities are can depend on your business and industry, but we’d suggest keeping your systems upgrade roll outs in the ‘quieter’ patches.

Going live early means that your team has the full working week to resolve any issues that may arise. Many organisations’ natural down time is on the weekend, but if your staff don’t work weekends, we’d advise against going live on a Friday. If your business continues to run as normal (or even gets busier) during the weekend, choose a time of the week that’s historically the quietest, and make sure you have ample time with developers just in case anything goes wrong.

A roll back plan should include a step by step the process to reinstate the old system with as little disruption as possible. If you can go with the approach of running parallel as we mentioned earlier, even better.

Need a hand with your Legacy System? Feel free to get in touch with us.