• If you are reasonably up-to-date with technical upgrades, it is best to keep the two projects separate. Do not make one dependent on the other if it is not really necessary. The decision would then be whether to do the business configuration refresh first, or the technical upgrade. It does not matter whether the implementation of one follows the other in a very short space of time, but it is not advisable to mix the technical change issues with business change issues unless you have a good reason to do so.
  
• If you are a long way behind on the technical upgrade path you can choose to skip the upgrade work in between and build a new instance, probably on new hardware and supporting infrastructure. This way the budget you may have put aside for the technical upgrade can be used to fund your complete refresh. This could be a very good reason for combining the technical and business change.

Planning a refresh
Like any initiative, it is necessary to have a good business case. However this should not be too difficult to achieve as, if you can make a good case for a system refresh to make the system more efficient and effective, then you should be able to make a good financial business case to support it.

• Project plan – there should be a clear project, with a proper manifesto, agreed scope, budget, timescales,governance and object
• Communication – it is important to engage and involve all stakeholders of the system to understand their
  requirements and needs. You need to maximise your gain from the exercise and build the best business model you can. Document your design and get the stakeholders to sign it off
• Training – this can be a very important aspect of a refresh. It involves not just explaining how to use new features, but how old features are presented in a new way. It is also an opportunity to reinforce business procedures and to explain techniques and methods that may not have been properly understood before.