Upgrading an enterprise application can be a stressful and time-consuming proposition, requiring coordination and input from lots of teams across your organization. Propper planning is of utmost importance to ensure that a system-wide software suite is upgraded efficiently and quickly with minimal risk to a business process and the end-user community, and oftentimes requires several project plans, timelines, architecture diagrams, and lots of meetings to ensure success.
We’d like to share a few tips and recommendations with you that Shamrock has garnered through our 20+ years of software upgrade experience. These will help ensure that your organization is best preparing for your enterprise upgrade project and ready to tackle any challenges that may come up!
First off – do you need to upgrade?
Most enterprise software upgrade projects are triggered via a need to remain complaint with internal IT or a software vendor’s best practices, or a desire to take advantage of functionality made available in a newer software release. Upgrades can be time-consuming and naturally incur some amount of risk, and for that reason many individuals are hesitant to upgrade their environments, but with proper planning this can certainly be overcome. In some cases, an upgrade may not be needed if the software system is operating as expected and is compliant with all involved parties.
It is worth understanding what new features and requirements will be available to you in a new software version when setting out on planning your next upgrade. Some software vendors may not make all this information available prior to the software’s official release, but in general it is possible to have an idea of what to expect via vendor newsletters, online documentation, user forums or conferences, etc. If possible, gather and digest what documentation you can regarding new functionality and technical requirements at the outset of your upgrade project.
Consider who will be performing your upgrade – if you or your team are not experienced with enterprise software upgrades, it is recommended to consider bringing in a third party to assist with any unfamiliar functions of the upgrade process. Expertise can make the difference between success and disaster.
Speaking of Documentation…
Properly documenting and tracking an upgrade is a critical component in making the project a success, especially if it impacts a large portion of your user base. The exact documentation needed will vary from organization to organization, but in general it is a good idea to create and maintain the following:
Technical project plan – this can take many forms, but at a high level it should be a place to record any/all technical steps required to perform the upgrade, a record of all needed resources (servers, stakeholders, etc.), report and prioritize issues, record testing progress, notes and “gotchas”, or a number of other functions. At Shamrock, our technical project plan servers as the nervous system for an upgrade project – a place where our team and yours can come together to record all technical notes pertaining to an upgrade project.
Timeline document – depending on your organization and the stakeholders involved in the upgrade, it is a good idea to keep a timeline document updated that will reflect the intended crucial dates for the upgrade, to be distributed to all involved at regular intervals.
Technical guides – installation guides, technical specifications, user testing plans, client installation procedures, etc. are all great resources to have on hand should an issue or unforeseen roadblock present itself during your project. It is far better to have access to these in advance of a project rather than needing to identify or find them when an issue arises, and most (if not all) of these items are available from the software vendor.
Testing/validation and issue tracking – the testing of an upgraded software is the most important component to an upgrade. Ensuring that all normal daily business functions are operating as expected prior to a Production go-live will help ensure success and avoid potentially disastrous interruptions to business should something go wrong. Where possible, provide your validation users with recommended testing steps and work with them to track and prioritize any issues for reconciliation.
Proper Communication is Key
As noted above, the testing and validation component of an upgrade is absolutely the most critical piece of a project to consider and plan for. Setting up a new server/software environment and adhering to best practices is important, but it is very likely that there will be new features or functionality that will impact your business process (depending on the software set and frequency of your upgrades). Ensuring that your end users have validated the system is critical to mitigating risk during the final cutover (or “go-live”) to the new software.
Oftentimes it makes sense to pull in supervisor or managers of business teams to lead testing efforts. Ensure they have a clear understanding of the upgrade project and the importance of testing, and provide them with the documentation noted above. Users should be able to complete their daily business tasks in the new software suite prior to go-live. Should a software bug or process change be required, it is much better to identify that in a not-yet-live system than scrambling for a solution post go-live.
General Upgrade Process
No two upgrades are ever quite the same, even within the same product suite, but below you will find an upgrade methodology that suites most enterprise applications and is frequently what is used for upgrade projects here at Shamrock.
New software environment creation (Pre-Prod and/or non-Prod environments).
It is very likely that the new software components have different technical requirements that what may currently be in use. Setting up the new software on a new set of servers while adhering to best practices is important. Depending on your upgrade team’s aptitude and familiarity with the software, this may take anywhere from 2 weeks to a month or more.
Our best practice at Shamrock involves creating a “Pre-Production” environment – installing, configuring, and testing the new software on a set of servers that will eventually be promoted to full Prod at go-live. There are numerous benefits to this approach – namely risk aversion, but also confidence that the future Production software components have been fully vetted as they exist at go-live.
Depending on your organization’s requirements, a non-Prod environment can also be created or tested before or after go-live. Regardless of timing, if a migration to new servers is required, we would highly recommend the “Pre-Production” upgrade approach noted above regardless of when a non-Prod environment is created.
Testing/validation.
This process (the most important piece, remember!) is the most flexible for an upgrade project timeline. In general, we recommend 4 to 6 weeks of UAT/validation to ensure that any/all needed users have time to validate the software fully. Regardless of timeline, it is critical to ensure that your user base has fully tested and signed off on the software functionality prior to go-live.
Go-Live.
The big day is here. Up to this point, the software should have been fully vetted, a plan should be in place for taking current Production offline and migrating everything over to Pre-Prod, and user should be aware of any upcoming changes. A go-live timeline can again vary depending on the software/upgrade process at hand, but in most instances it’s possible to decrease an outage window to only 4-6 hours if utilizing the Pre-Prod upgrade methodology noted above.
You didn’t forget to take backups prior to go-live, right? Always take backups, of everything – take full database backups, snapshot all VMs, save off copies of individual client-side settings, etc. There are never too many backups.
Non-Prod environment creation and upgrade/environmental clean-up.
Post upgrade
The time period immediately after go-live can be a bit turbulent, but it can be minimized with proper planning and resourcing. Depending on your organization, the business units involved in the upgrade many need to have a 1 to 2 week “hyper care” period, ensuring that their issues are addressed in a timely manner.
Once the dust from the upgrade has settled and your user base is happily using their new software, it’s worth stepping back to take a look at how the project has gone and prepare for next time. Check out our “You’ve Upgraded, What’s Next?” article here for more on that!
Jordan Wengler, Technical Services Manager
Comments