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.
