Set legacy applications to read-only

 When preparing to go live with a new application, the set up and testing of access to the new application is necessarily part of the work. What is also needed is to prepare a plan for how you will change the legacy application(s) being replaced to read-only.

It’s a common enough statement… let’s make the old system read-only so users can look things up for a while. But why and how to do that?

The first, most immediate reason to keep the application read-only is to allow users to inquire and run reports so they can validate the data converted to the new system.  The next user of the read-only access will be the auditors, either internal or external or both. Whether they log on directly or ask the business to run reports of the data converted, read access will be needed to support the audit.

Over the longer term, the business may require ongoing access to the legacy system for a variety of reasons, which will vary depending on the kind of application it is. For example, regulatory audits, addressing disputes with suppliers or customers.

Businesses generally change the legacy applications to read-only (instead of just continuing with update access) because no matter how much training and communication is provided, if there are more than a few users, someone in the organization will continue to make entries in the old system unless it is specifically prevented.

Start with the requirements

The starting point is to identify requirements for the access changes.  Someone on the project team or in the business will be developing a cutover plan, defining the steps for opening up the new application. Planning for the changes to legacy access needs to be aligned with the cutover plan. For example, if the last Accounts Payable close date will be March 20, the date to stop approving supplier invoices is likely also March 20. 

Where’s the read-only switch?

The next step is to identify how to set the specific functions to read-only in the legacy application.  There’s generally no read-only switch, and you have to figure out how to do it for your specific application. You’ll need to work with the subject matter expert for each legacy application.

Every application will be different and some will be easier than others.  The easiest is when there’s a read-only role already established and every user can be re-assigned to that role on the specified date.  Another simple method is to leverage existing application settings that support standard business processes. For example, accounting applications often have a setting to prevent posting to closed months, so if all months are closed, no one can post accounting entries.

Sometimes, especially with ERP systems, users will need their Accounts Receivable, Accounts Payable, Fixed Assets, and General Ledger access changed to read-only on different dates.  In addition, there may be a few corporate accounting folks who need to retain their access for a few weeks longer than divisional accountants.  These kinds of situations often require changes to existing roles, or creation of new roles in the legacy application. If there are a lot of users or roles for which access changes are going to be made, it may be necessary to run script updates instead of changing them manually one-by-one.

Some systems don’t really have the kind of flexible roles that exist in ERP systems.  In these cases, making access read-only may require setting an end date on an entity, changing to a different license type, or modifying workflows.

It is common to keep a very few users with admin access so they can continue to add or remove users as needed in the future.

Testing access changes

The amount of testing you need to do will depend on what approach is taken. New roles, script updates, or other approaches will require more testing than assignment of users to existing roles.  Document the testing approach, results, and approvals, and save them for audit.

Controls/approvals

Identify and document approvals needed for execution of the plan. If the plan is approved, are there further sign-offs as each step is executed, or is approval of the plan enough to proceed with all of the steps?

Process for exceptions

What will the process be once changes to read-only are done and there is a business need to continue to execute? For example, if all of the invoice approval workflows have been turned off, and there are invoices that really must be processed. Identify in advance how that situation will be accommodated, and who will approve that change when it is requested.

Service desk
Remember to advise the service desk and user provisioning team of the access changes being made. Provide them with a script for what to tell users who missed the training and didn’t read the emails, or who forgot the deadline. You don’t want the support team granting update rights to users who are not supposed to have it any more.  

Document the execution

Document any access changes needed for audit, and identify where they are to be stored. Create the documents as you execute the steps, and file them as you go. 

Conclusion

When you implement a new system, it is likely that you need to change access in the legacy system to read-only. This article provided some high-level guidance to get you started. You can modify it to suit your own project’s needs.

Retiring applications

A frequently-neglected part of the plan for implementation of a new application is the retirement of the one that is being replaced.

However, there is good reason to do that work at the same time as your new project, as there are risks and costs related to keeping an old system running after it is no longer actively used.

Why decommission

The most obvious concern with maintaining applications that are no longer used is the cost of licensing and support agreements. There are also less obvious costs. For example, you may be running certain hardware or operating systems for the sole purpose of maintaining the legacy applications. You may also pay consultants with legacy expertise to maintain that legacy hardware and software. Perhaps it is no longer feasible to apply some types of security to older systems.

Here is an approach to consider and tailor to your own application and organization.

Business ownership

Although managed by IT, there must be a business owner who will participate in retirement planning and approve any decisions that are relevant to the business.

Contracts

Unless the application being retired is fully home-grown, you likely have some contracts in place. For example, application licenses for users and administrators, and support agreements. The infrastructure or security support may also be covered by service contracts. Review all of the relevant contracts and determine what your rights and responsibilities are. E.g. if users are not maintaining any data, but are read-only, do you still have to pay? What is the notice period, and when is the deadline to give notice? Are your responsibilities truly clear in the contract, or do you need a lawyer to review it?

Continuing access to the data

Depending on the business use of the application, it may be necessary to keep the data for some period of time. Start by identifying the data that is kept in the system. Is it general ledger, purchase orders, energy usage? Also identify whether the application is the system of record for that data. If the application is just for reporting or transmitting, and the system of record is somewhere else, it may much easier to eliminate the application’s data set.

If the application is the system of record, map the data sets in the system to the corporate data retention policy. This policy will have been developed in alignment with compliance, legal, and regulatory requirements. Then, discuss with the business owner what their business needs are for ongoing access to the data. This may be different from the corporate data retention policy.

While you’re having that discussion with the business, find out what kind of access to the data is going to be needed. Do they still need to use the application to view the data, or will it be enough to be able to query the database?

Also ask the business owner how many users should have continuing access to the application. Perhaps you can reduce the number of users to just a few, either right away, or after a year or so.

If the application being retired is on some technology that you no longer use for any other applications, it may be tempting to copy the database to a technology that you support as a standard. However, this may not provide what the business needs. If the data structure is complex, you may no longer have an employee with the experience to query that structure and get the right answer. In addition, if there is a need to re-generate reports or documents, it may not be feasible to do so without the application.

Operations

Perhaps based on either the retention policy, or the business needs, you have learned that the application is still needed for inquiry and reporting for several years. There still may be steps you can take to reduce the effort of operating the application.

For example, since the data isn’t changing, it may not be necessary to do daily backups or manage high availability. Perhaps the business would now be fine with a monthly backup, so you have fresh media. Maybe the business would agree with a longer recovery in the event of failure.

It’s also likely that you could eliminate the development and testing environments for the retiring application.

Security and controls

You can also examine the security and controls for the retiring application. For example, discuss with the business whether they still require two-factor authentication.

It’s also a good time to discuss whether the controls for the application and its supporting infrastructure should be tested any more as part of the audit. Some of the testing may no longer be needed, which could reduce the effort of internal or external auditors.

Other considerations

If you are generally moving applications to the cloud, or no longer wish to support the particular technology platform of the retiring application in your data centre, you may consider options to have someone else manage it for you. There are usually vendors who would agree to host the hardware and application in their own data centre. Note that this approach requires considerable planning, and you should engage the potential vendor early to discuss requirements.

Conclusion

When you implement a new system, planning for the retirement of the old one should be planned at the same time. It should be possible to manage costs and risks by appropriate planning and execution.

This article provided some high-level guidance on retirement planning to get you started. You can use it as a framework, and customize it to your own organization’s needs