What Should You Expect During Your ERP Upgrade?
What should you expect when upgrading your ERP solution? In a word: disruption – at least a little bit.
If you use your Enterprise Planning (ERP) solution in a 100% vanilla-manner, then this probably doesn’t apply to you. For the rest of us, direct involvement in an ERP upgrade is required to ensure that the configurations and customizations made to your existing solution work as needed.
Specifically, you and your partner will need to address potential conflicts between 1) what was done to cater the existing solution and data to meet business needs and 2) what the software vendor has added to the out-of-the-box solution in the more recent version(s). Whether your ERP solution handles those customizations directly in the business logic, as added layers, or completely external to the system, conflicts will inevitably occur.
Your partner will help address those conflicts by enhancing data upgrade tools to include your structural changes, merging your custom business logic into the new solution, possibly removing customizations no longer needed, addressing any security changes needed for the new version, and generally testing the system to ensure consistency.
Your team will be impacted to a moderate degree - in testing iterations, possibly some joint-process-(re)design sessions and, in some cases, formal end-user acceptance testing. Likewise, the release of the upgraded application and environment will probably cause efficiencies to decrease slightly in the short-term as everyone gains familiarity with changed interfaces, new functionality, and altered workflows.
On the bright side, and unlike remodeling a house (using the analogy from Part 1 of this series), an upgrade project does not actually impact your live environment until the release/go-live date. Therefore, during the project, you are not trying to work in a kitchen without counters or a room without flooring. Your use of the existing production ERP solution should not be limited in any way until you finally execute the upgrade at go-live.
Phases of an ERP upgrade
A typical ERP upgrade includes the following phases (order may vary depending upon project approach and business requirements):
1.Technical Upgrade: Your partner merges code from the current version of the application to the new version of the application
2. Server / Environment: You partner or your internal IT staff builds or updates the server and infrastructure to support new application
3. Test Data Upgrade 1: A test instance of the application is loaded onto your network, generally including an initial pass at upgrading your data
4. Integrations: External systems with integrations or touch-points to the application are duplicated in a test environment (or redirected as needed for testing)
5. Key Training: Key users are trained on the new version of application
6. Test Workflows: Key users test the new version of application
7. Iterative Changes: Any reported issues, workflow conflicts, or security conflicts are reported to the partner and are addressed
8. Test Data Upgrade 2: [Optional] A second test run of the upgrade is performed – typically if some data conversion issues were discovered in testing
9. End User Training: Key users train end users
10. User Acceptance Testing: End users test their respective processes - for workflows, outputs, and permissions
11. Go/No-Go Decision: Go-live/conversion date is confirmed (with conversion activity typically targeted for a weekend)
12. Release: GGo-live/release of upgraded solution
13. Support: Post release partner support and issue resolution
Testing
Unfortunately, this process is not perfect unless you overspend to avoid any potential fallout. With that in mind, there are generally two ends of the spectrum when we consider the approach to testing:
- On one end of the spectrum, no testing is performed and any conflicts or issues with the code and data migrations are addressed after go-live. In fairness, this approach is often the cheaper one – even when post-release costs are included. Unfortunately, it also increases user frustration, limits adoption and acceptance of the new solution and leaves your whole team with a general distaste for the product and upgrade process.
- On the other end is over-testing. The argument here is for spending whatever it takes, in terms of hard dollars and internal resource time, to ensure that not a single surprise surfaces after go-live. While obviously much more expensive, this approach also tends to “burn out” the users on the product and their own processes. In return, the go-live will almost assuredly be worry-free.
The reality is that you should fall somewhere in-between – based on your budget, user preparation for some iterative post-go-live pain and the time-sensitivity of your processes and data.
If your go-live is fully pain-free, then you:
1) May have over-invested in testing
2) Had no conflicts in your customizations
3) Got very, very lucky
Instead, you should aim for full testing of critical processes and light-to-moderate testing of non-critical processes. If you are able to then absorb the incidental issues arising after go-live within the first few weeks, you have probably struck the perfect balance.
Check out the other posts in this series, Why Upgrade Your ERP Solution? and Getting the Most from Your ERP Upgrade.
If you're planning an upgrade and would like to visit with our team for next steps, please contact us.
[button title="Let's talk about an upgrade" link="/contact-us/" new_tab="yes"]
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.