Why Your Company Needs an ERP Disaster Recovery Plan

By: Siva Ramamurthy    July 10, 2024

Given the role enterprise resource planning systems (ERPs) play in helping organizations run their business, it’s safe to say they’re incredibly important. But what happens when something beyond your control goes wrong?

This is where the necessity of a disaster recovery plan comes into play. So, if your Lawson ERP is hosted on-premise or by a non-Infor provider, you need a disaster recovery plan in place.

In this post, we’ll explain the significance of a disaster recovery plan, how to create and test one, and the different types of disasters that may warrant you to put the plan into action.

What a Disaster Recovery Plan is, and Why You Should Have One

Several different kinds of disasters can affect your organization’s ability to operate. These include natural events, such as earthquakes, fires, floods, or storms, as well as system failures and human-related problems such as a malicious attack.

You’ll want to have a disaster recovery plan in place to bring your systems and infrastructure back up to speed in case of an unplanned event. Such a plan will allow your company to quickly get back to normal operations by restoring your computer hardware and software, as well as your data.

Having an effective disaster recovery plan in place will also help ensure your organization is prepared for worst-case scenarios—from a heavy financial impact and loss of productivity to stalled services and severe reputational damage.

A disaster recovery plan is also a great way to help your employees understand emergency protocols, so your company can return to providing products and services as soon as possible.

Creating a Disaster Recovery Plan

When devising a disaster recovery plan, there are five key steps you should take to get started.

1. Make sure your data is backed up: To help ensure disruption to your business is minimal in the event of a disaster, back up your data—at least once every 24 hours. The “3-2-1 rule” of backup is a good rule of thumb: be sure to have three copies of your data, on two different types of media, with one copy stored offsite. Also, along with your data, be sure to back up your product keys and software license keys, which certify that a copy of a program is official and paid for. You’ll want to have these readily available to reinstall software without delays.

2. Identify your disaster recovery team: This group of people should have thorough knowledge of the plan and be able to discuss it with your company’s leadership team and key stakeholders. They should also meet on a regular basis to test and update the plan as needed. Your team should be responsible for listing the people that need to be notified in the event of a disaster, as well as what their specific duties are. This includes database, server, and network administrators, as well as application support staff. It can also be helpful to have an expert third-party partner on your disaster recovery team. A proven technology partner, such as RPI Consultants, can help with documenting this critical information as well as provide specialized expertise, testing support, and resources during a crisis, enhancing the reliability and robustness of your recovery plan.

3. Inventory your hardware and software: According to ready.gov, it’s crucial to “identify critical software applications … and the hardware required to run them.” Best practices recommend using standardized physical hardware for an on-premise system, as it’s easier to replicate and reimage quickly. Many cloud-based systems, like Infor CloudSuite, include disaster recovery as part of the subscription, which includes data and maintenance backups. Outside of your core ERP, however, you’ll want to make sure you keep backup records and recovery for your point solutions, as they may not be included in the core disaster recovery plan.

4. Put your plan to the test: In the time-honored tradition of “fire drills,” it’s valuable to practice your disaster recovery procedures regularly (at least once a year)—and before you actually need them. In this way, your team will become familiar with the tasks they’ll need to perform and be able to do them more efficiently. Testing your plan also enables you to identify any issues with it ahead of time. Moreover, it provides an opportunity to run through the exercise of recovering your system as if it were actually happening. This can help with ensuring uptime requirements are adhered to and will dictate the best type of site recovery for your organization, but more on that and testing below.

5. Update your plan periodically: Organizations, and the technologies they use, change quickly. So, it’s a good idea to look at your disaster recovery plan with a critical eye on a regular basis. This will assist you and your disaster recovery team with anticipating and resolving problems, allowing you to proactively make necessary updates to your plan.

Key Disaster Recovery Plan Considerations

As you devise your ERP disaster recovery plan, you’ll want to keep the following recovery time, objectives, and documents in mind. Here’s why:

1. Your recovery time: Take note of the consequences involved in having your company’s operations shut down. How bad will things get the longer it takes to recover?
2. Your objectives: Identify your recovery point objective (the point in time to which data must be recovered after an outage) and your recovery time objective (how long will it take to get your data restored).
3. Your planning documents: You and your disaster recovery team need to be able to reference relevant documents if your system goes down. Make sure they’re accessible from outside the system.

Key Components of a Disaster Recovery Plan

1. Knowledge of the risks: Your team should determine what potential hazards exist: natural disasters, technology problems, and human-caused issues. Knowing the potential threats will help your team figure out which tools and techniques to use to recover from specific types of catastrophes.
2. A list of short-term priorities: Rather than focusing immediately on a long-term solution, your organization should identify which operational capabilities should be restored in the short term. Some items, such as resuming cash flow and payroll processing, should not be back-burner. A reports, interfaces, conversions, and enhancements (RICE) inventory can assist with documenting your organization’s unique system configurations and integrations.
3. Essential files: Back up your most recent financial statements, contact information for key individuals, inventory records, tax documents, and lists of clients and vendors. Again, don’t forget to have copies of software keys and licenses at hand.
4. Key outside partners: Know which external teams to involve; for example, your server and database system administrator contact information should be readily available and documented in your disaster recovery plan. For core ERP software, like on-premise Lawson, for example, you’ll want to have your ERP partner point of contact information readily available as well. This will help in ensuring the system goes up and integrates with your related systems without any trouble.

The Role of Secondary Sites in Disaster Recovery Plans

Having a secondary site for data storage is key to your disaster recovery plan if you’re using an on-premise ERP solution like legacy Lawson. Software will use data backups from your secondary site to restore your primary servers if necessary. There are cold, warm, and hot secondary sites and determining which is right for your business will depend on cost resources and required uptime:

• Cold recovery site: Cold recovery site is a target environment that needs to be activated once a recovery process is initiated. Infrastructure exists but needs to be started up and fully launched. In some cases, new virtual machines need to be set up, databases and applications installed, and data restored. This environment might sometimes be used for devilment and testing and can be repurposed for disaster recovery at a time of need. As a result, costs are much lower for a cold site.
• Warm recovery site: Warm sites include the elements found at a cold site, with the addition of storage hardware, such as disk drives and servers. Data will still need to be sent to the site in preparation. In between a hot site and cold site, a warm site is where you may have computer/virtual machine available on standby that can be easily connected to your recovered (or already replicated) data. Costs range in between a hot and cold site.
• Hot recovery site: Hot sites are where the target environment is already up and running and can be immediately activated by a failover. There are also high availability architecture options where you can have multiple nodes in a clustering or load balancing setup. In those cases, an outage of a single node does not impact availability. Essentially, a hot recovery site includes two or more instances of your production environment activated, and therefore would incur significant costs. Anyone operating a hot site, then, is multiplying IT costs by two or more times. Again, these types of sites are necessary to support on-premise or non-cloud based hosting solutions; having a cloud-based solution like Infor CloudSuite, however, renders most of the related issues moot.

Disaster Recovery Plan Testing

According to TechTarget, “experts recommend conducting disaster recovery tests on a regular basis.” They also suggest “incorporating them into all planned maintenance and staff training.”

After each test, organizations should analyze audit logs and other data to find out what worked and what didn’t. Doing so will inform any necessary revisions to the disaster recovery plan; it will also identify areas and tasks that need to be retested sooner rather than later.

RPI recommends scheduling annual disaster recovery exercises annually, and selecting a dedicated month for disaster recovery-related activities. We also suggest having a regular review of your disaster recovery plan.

If there are major changes to your software or hardware topology, we recommend doing an off-cycle disaster recovery exercise to make sure that the plan accounts for changes in your environment.

Get Help with Disaster Recovery Planning

If you have a non-Infor hosted ERP, RPI can assist with disaster recovery planning and support if your systems go offline. Whether on-premise or hosted by a third party, we provide disaster recovery planning, strategy, and documentation to help your organization manage future needs independently.

If you’re on legacy Lawson and maintaining a disaster recovery plan is something you don’t have the capacity to worry about, consider migrating to Infor CloudSuite before the software’s end of support in 2030.

Infor CloudSuite is gaining popularity among healthcare, the public sector, and utilities. One of the benefits of the cloud solution is that it already includes built-in infrastructure for data storage and provides tools to assist with backup processes and disaster recovery. To learn more about Infor’s CloudSuite solutions, including the difference between single and multi-tenant environments, check out Infor’s CloudSuite Solutions page.

Because Infor is responsible for managing the disaster recovery policy through its continuity plan, you’ll be able to scale rapidly and keep your company data safe should a disaster occur in or near your location, while also saving the money required to create and maintain an on-premise solution.

Now more than ever, savvy organizations need to be prepared for natural or human-caused disasters, so they can recover quickly and resume operations as fast as possible.

For more information on how RPI can help your organization update your disaster recovery plan or create one from scratch, contact us below.