When Your ERP Software Is Being “Sunsetted”

Back to Knowledge Bank
Posted by: briansittley Comments: 0 0 Post Date: February 19, 2019

In our world, “sunsetting” is the delightful euphemism used by big software companies when they are putting one of their older software products out to pasture.  Many of our clients have had this experience in recent years with the demise of a wonderful old product that was originally called “SBT Accounting Systems” but which, after two successive corporate acquisitions became, first, “ACCPAC Pro Series” and finally “Sage Pro ERP.”  In all cases, the core product remained the same as each successive owner tinkered with the dials and upgraded and improved the product over time.

Eventually, a number of years ago the final product owner, Sage Corporation, a U.K.-based behemoth of a software company that had acquired hundreds of smaller players over the years, made the decision to “sunset” Sage.

These decisions happen for a variety of reasons known truly only to their owners, but generally based upon declining revenues and future revenue projections.  Ultimately, the sage folks at Sage decided that Sage Pro was no longer fitting their model – for reasons easily surmised but too lengthy perhaps for a short blog post.  And so a future date five years out was announced and eventually the final version of Pro was released, about five years ago.

To this day, we still support clients running various old versions of Pro.  But as operating systems progress, languages become discontinued, publisher revenue models change and software features evolve, these companies all face the same daunting task: How does one replace a sunsetted system?

We’ve helped a lot of clients through that muddle, so let us offer some advice, shared by other consultants in one form or another in various forums over time, which we think all clients pondering the question can benefit from.

First, recognize the truth. Your product is being discontinued.  No reason to panic, but every reason to plan.  This is the perfect time to take stock of what you love and hate about your current system.  What would you do differently next time?  What is indispensable about your system today?  Are there features or functionality once deemed important but now seldom used?  Could your system be doing more for your users?  Do you have your data in one repository, or scattered over many?

There are more of these sorts of questions to be answered, so the first piece of advice as you start your plan is simple: Gather your stakeholders (your management and your users) and work through the questions – the ones above, and others of your own devise.  Let everyone have their say at this stage, and listen carefully, looking for pockets of inefficiency in the way you process your orders and run your business.  The folks using the system are usually the best at finding what’s wrong with the system, and can be a goldmine of information on how to improve your business.

Second on the list: Develop your (transition) plan.  Whether the replacement software is a comparable offering from your current provider, or an all-new option, be open to new ideas.  How will you migrate your data (and which data)?  Will you go for on-premise or in the cloud?  There are peculiarities and gotchas — with associated costs — to both.

Here’s a little tip by the way: in this day and age, the cost of staying with one solution provider or moving to another, or of moving from Software A to Software B, given similar capabilities, will be roughly the same regardless. So relax, focus on fit and functionality within a general range of functionality, and worry about the costing later, because they’ll all be roughly the same.

Third, take time to review and then re-engineer your business processes.  This takes time, so continue to run your old system even as you look for ways to improve the overall business by implementing a newer, more modern, and usually easier-to-use system.  When evaluating replacement alternatives, be sure you work with your provider to get a sense of how your present-state reality will morph into your future-state environment.  Capture best practices now so they can be incorporated into your software when the time comes.

Finally, prepare your team(s).  Software transition processes can be time-consuming, frustrating, challenging and confusing.  And on top of that, you and your employees still have a business to run!  Be sensitive to this fact.  Consider hiring temps through a transition.  Allow ample time for the transition period – and then double it to be safe.

This is just a broad outline of what you need to think about as you move from a sunsetted product to your whole new dawn of new software.  Take your time, then as we like to say: plan the work and then work the plan.

Leave a Reply

Back to Knowledge Bank