Get off that Legacy Composition System before it’s too late
Back in the day, late last century, if you wanted to send out something to a customer, you needed your IT “guy” (used generically; your guy could’ve been a gal) to help you out. They gathered data from some system, usually some financial system or database; and then they put it into some reasonably readable form. That’s when the “Legacy” homegrown Composition Tools were born. Over time, after some smart university students started to use some super computers that were no more powerful than your smart phone, off the shelf products came to market.
So, here we are, a few decades later with new challenges. We still want to communicate with our customers in a clear and concise way, but our customers have flipped communication upside down by wanting to communicate with us too… and instantly! As in, less than 2 seconds or they will get frustrated and deal with the faster, better communicator – your competition!
Changes in Document Composition Software Requirements
Those old systems simply cannot keep up or do the things that your employees and customers want them to do. Things like helping with your C-suites’ Customer Experience Management initiatives or integrating with other major software systems that your business runs on such as CRMs, Line of Business Applications, and Accounting Systems. Everybody wants a system of integrated applications to manage their businesses and automate many back-office functions.
Now what? It is time to source a new Composition System that will provide key functionality or integrate to things that weren’t even invented when your last system was put in place.
We all have smart phones! Mobile customer communications and responsive digital communications that scales on whatever screen it is being consumed on is a given. Heck, it’s the ante or table stakes.
Not everybody wants to write code! Line of Business (LOBs) knowledge workers want to have the control to create their own content without having to wait on the “guy” in IT. The LOBs want to edit communications without breaking anything for IT and they want to stay on brand to keep Marketing happy.
Nobody wants to make a mistake! Actuaries are analyzing every customer interaction, Compliance and Governance folks are ensuring new regulations are being followed and Legal does not want to get sued.
What do you do next?
Even if you wanted to keep that vintage, stable software, you know that the only guy or gal that can program it is going to retire any minute or the vendor is not going to support it anymore. It is time to upgrade, migrate and send that trusty composition tool out to pasture.
According to it-checklists.com, “Application Retirement” means different things to different people. In general, they state that “[it] discusses the process of upgrading an application to a newer version or replacing [it with] another similar product.”
In general, the application retirement is being done for one of four reasons:
- Replacing an old version with a newer version of same application
- Removing an application which is obsolete and not used any more
- Removing an application because it is replaced with another application
- Removing an application because it is replaced with a module of a bigger application
Regardless of your organization’s particular situation, it is often not a revenue generating project and this type of project gets stuck until someone deems it financially mission critical to the business or you simply have no choice.
5 Steps to Making the Software Migration Plunge
Most people in IT departments have not experienced many major enterprise software deployments and decommissions in their career to get the job done efficiently. Depending on the maturity of the IT organization, employing some consultants that have been down the road before can help you to avoid some serious pitfalls. This is not a time to conduct on the job training, unless there is a very seasoned mentor for the up and comers. Regardless, if you are doing it yourself or working with a team like WayPath that does it every day, there are certain steps that you must think about and execute well.
Step One: Assess the current situation and establish the business case
The CIO or VP, IT needs to ensure that a solid business case has been built to ensure there is enough budget and resources to finish the job. They also need to align the project with the company’s mission. It is also critical that this senior project sponsor has some inter-department collaboration skills to get things done as many parts of the business could be affected.
A detailed assessment of the current state should be documented to ensure that tangential or other integrated systems and departments are not adversely affected. They should all be addressed during a workflow and stakeholder assessment.
Step Two: Back up the old system and create a new test environment
Software Migration/Upgrade 101, states that you need to make sure that you don’t break anything or lose any information. So back that system up before you start working. You should be doing this on a regular basis anyway. By the way, the data in the old system may need to be archived for other compliance reasons.
Organizations should also prepare multiple environments for the new software to be deployed, yes even if it is in the cloud. At minimum, there should be a test and a production environment built. As stated above, a backup environment should be in place from the beginning and it should be part of a larger business continuity plan.
Step Three: Plan
The Project Management Office (PMO) and/or Project Manager need to create a project plan and ensure that the plan does not experience scope creep and budget overruns. The PMO will also be responsible for the launch of the new software and the decommissioning steps as well.
An often overlooked and underestimated step is the Change Management element. The staff that will be affected by the new software need to be made aware of the need for the change and should participate during the acquisition of the software. They need to be trained prior to the launch to understand the new impacts to their jobs and their customers. The change then has to be reinforced and managed by senior and line management.
Other players that should be considered as team participants are Operations Managers, Vendor Management and Finance. Operations will ensure that the day-to-day activities are continuing and that there is no negative customer impact. Vendor Management will confirm good support from the new vendor while turning off all licenses and support agreements from the past vendor. The Finance team should be informed that certain payments will be discontinued and accounted for accordingly in depreciation tables.
If you are on the planning end, no matter what pressure you are under to deliver fast, there should be some buffer built in to accommodate for unforeseen events. These hurdles could be as simple as key players being sick or on vacation.
Step Four: Test, test and test again
User acceptance testing (UAT) should not be rushed. The Users need to trust that the new system will work, and the organization needs to be confident that it will not affect the current business operation. Often, Users want to have what they had before and more. In some cases, there is a new way to do things, so the features and functions may be in a new place or in a different stage of the workflow. So they need to be comfortable prior to Step 5.
Step Five: Go Live!
The PMO and the core project team need to create a checklist of all the conditions that must be met for system shutdown. Ensure the senior leader with the authority to shut down the legacy environment gives the go ahead before making any moves. It is critical to have a “go/no-go” time set, so the line of business and technical teams are also ready to ensure that everything is going according to plan. The launch time should be done at a time when the business is either closed or at a very slow time, so customers and users are not inconvenienced. Proper notice should be given to all parties to minimize calls and complaints.
There will inevitably be something that goes unforeseen, such as a rarely used integration point or exception process. To make sure there are limited complaints and the minor “bugs” are resolved quickly, the team should be on call for the first 30 days after the deployment to keep things moving along smoothly.
Take Inventory and be Proactive
Take the time to take inventory of your systems and be proactive in budgeting for the change. Budgets encompass not only money but opportunity costs, risks and resource’s time and energy. This should be done on an annual basis to stay ahead of the inevitable changes that will crop up; like having to get off that Legacy Composition System before it’s too late! You know, when your guy wants to retire or wins the lottery. If you think, I made this stuff up, contact me and I will tell you a few stories.
About the Author
Paul Abdool is the Chief Revenue Officer at WayPath. He uses his 20+ years of regulatory communications industry experience to help customers develop and optimize their customer communication strategies with process automation, workflow solutions and professional services.
If you are planning an enterprise wide Customer Communication Management (CCM), Customer Relationship Management (CRM) or Content Management System (CMS) software deployment, please contact WayPath Consulting to discuss your needs. www.waypathconsulting.com
