Upgrade or Migrate or Re-implement

A New Software Version is Available – Do You Upgrade or Migrate or Even Re-implement?

The Legacy Work Horse

The Legacy Work Horse

If you have been using a software system, ERP, CRM or other, for a good number of years the software you are running will have gone through revisions, updates, with new features and capabilities etc.  If you have kept your Maintenance/Software Assurance up to date you will have had access to these updates.

However, having access to the updates is not the same as having applied them.  One of the advantages of a true Software as a Service (SaaS) solution is that the upgrading is taken care of for you, sometimes if you want it or not.

 

This is not a discussion about the pros and cons of SaaS solutions.  This is looking at the issue of your current system getting to a point where it is many updates perhaps years behind the currently available release.

The years of legacy development and customisation of the old system are very likely to be out of date with today’s business requirements.  In many of the reviews we have been involved with, large amounts of “must have” customisation were found to be irrelevant when scrutinised closely.   They could even be holding the business back.

The other reasons to review the system is that with each new update, the core product will have gained new features and new technologies.  These new features may replace customisation or improve old processes and practices.  New technologies will provide better integration, stability, performance etc.  A more current version may have removed some of the old features, APIs may have changed, these will need to be managed whether you upgrade or migrate.

Furthermore, most businesses are trying to reduce the complexity and custom solutions so they can take future updates more easily and reduce their maintenance overheads.  This simplifying of the solution may mean some compromise on the ideal functionality, but the benefits can be significant, including better user adoption due to the easier leaning path of the new design.

What do you do?

The move from the older release to the latest can be quite a leap and costly.  You are perhaps facing not only a significant software update, but a platform change too, for example:

  • Upgrading the current hardware
  • Upgrading server/database software
  • Moving to the Online version of the solution – this is for another article

Upgrade

It is possible to upgrade, perhaps in multiple steps, for example:  you have to go from V5 to V6, then V7 to get to V8 and you will still need to upgrade the underlying server/database software as you go.

So, is simply upgrading the right choice?

What is the other option?

Upgraded vesion

The Upgraded Version – still has the old chassis though

These multiple steps are time consuming, the potential recoding, testing for example at each step add to the overall project time and risk.  Simply upgrading will not inherently mean that new features or capabilities are adopted.  You are basically looking at the same system you had, but on a current supported platform.  Although to get to that platform you may well have had to do some re-development as APIs, functions may have changed, been removed, enhanced etc.

Migration or Re-implementation

Migration would start with a nice clean empty V8 install.  Then migrate from the old to the new what you have and use, leaving behind the old obsolete function and data.

Re-implementation takes this a step further, starting with an in-depth review of current, and more importantly future business requirements.  Then reviewing these against the new features and capabilities of the new version of the software, configuring the new version to meet the reviewed business requirements, then migration of the data to the new implementation.

Same pedigree – with the modern touch

Same pedigree – with the modern touch

Leaving the old solution behind, will provide the opportunity to also leave behind the legacy of old redundant code, data etc.  When upgrading, this tends to be left in the system “just in case”.  This just adds to the confusion and maintenance overhead, because it gets to a point where no one is quite sure what is doing what – unless your system is very well documented.

 

The migration gotcha

The major overhead of the migration / re-implementation approach is that it will require a data migration project.

Migrating data from one database to another, even if the data structures are broadly the same, is not a trivial exercise. Do not underestimate this task.  It is not necessarily the volume of data that is the issue, although this will obviously have a bearing on the amount of time to migrate.  It is absolutely worth reviewing the data you have. Consider which elements might left behind, is the very old data still of value?  Now is the time to make that decision.

The complication with moving data is retaining the integrity and relationships.  You may also want to take advantage of new technology options for example:  Moving to SharePoint for Documents as opposed to documents held within the database of the old system.  An important consideration is the migration of users, particularly when some of those users have left the business.  Knowing that an activity, opportunity, ticket, order, invoice etc. was owned/actioned by Jane who left the business a few years ago, could still be very important.

There are significant advantages to considering the re-implementation option if you are moving from an older version of a solution.   Consider it an opportunity to simplify and re-tune the solution to the business as it is today, or more appropriately to your business of tomorrow.