Disaster Recovery Plan

DRP Table of Contents

Contents

CONTENTS…………………………………………………………………………………………………………………………………………………………………………..2

1. HIGH LEVEL OUTLINE OF DRP ………………………………………………………………………………………………………………………………………3

2. KEY PERSONNEL AND CONTACT INFORMATION ………………………………………………………………………………………………………….3

3. DATABASE BACKUPS ……………………………………………………………………………………………………………………………………………………4

3.1. PRODUCTION DB……………………………………………………………………………………………………………………………………….4

3.1.1. On-Prem Production DB………………………………………………………………………………………………………………………….4

3.1.2. On-Prem Migration DB……………………………………………………………………………………………………………………………4

4. DISASTER RECOVERY PLAN ………………………………………………………………………………………………………………………………………….4

4.1. FAILURE TO MIGRATE – XXXXXXX …………………………………………………………………………………………………..4

4.1.1. Failure of Migration from On-Prem to Azure……………………………………………………………………………………………..4

4.1.2. XXXXXTesting……………………………………………………………………………………………………………………………………4

4.1.3. XxXXTesting ……………………………………………………………………………………………………………………………………………..5

4.2. FAILURE TO USE AZURE – XXXXXXXX ……………………………………………………………………………………………….5

4.2.1. Failure of Azure Production ……………………………………………………………………………………………………………………..5

5. DATA RESTORATION PROCESS …………………………………………………………………………………………………………………………………….6

6. INCIDENT IDENTIFICATION AND PRIORITY GUIDELINES…………………………………………………………………………………………………6

1. High Level Outline of DRP

The purpose of this Disaster Recovery Plan (DRP) it to outline the actions that are to be taken XXXXXXXXXXXXX is unable to cutover to the Azure Production DB (Azure) environment at the start of business on XXXXXX. The document will serve to define potential risks that may contribute to these steps being implemented and the restoration process for XXXXX to cease its attempts to connect to Azure and as a result connect to the original On-Premises Production DB (On- Prem).

XXXXXXXX will undertake to migrate the On-Prem environment starting after XXXXXXXXX. Based on previous test case scenarios, this process should be completed by midday on XXXXXXXXXX. XXXXXX will be on standby during this phase in case assistance is required.

XXXXXXXXX will undertake basic user connection testing and once complete hand over to XXXX to undertake a more robust user connection test ensuring all user desktops can connect to Azure. On success, XXXXXX will confirm its acceptance to move to Azure from XXXXXX. Monitoring will be conducted from the start of business and the parties will communicate results of usage and report any issues as they arise according to the incident identification and priority guidelines below.

IMPORTANT NOTE:

This document only deals with incidents that will potentially lead to this DRP being implemented. It is not intended to capture normal business process and user issues outside of the scope of this DRP. Any issues outside the scope should be addressed through the normal channels and directed to the appropriate parties.

2. Key Personnel and Contact Information

3. Database Backups

3.1. Production DB

3.1.1. On-Prem Production DB

For the purpose of this DRP, existing backups will continue up to and including the XXXXXX. After this XXXXXX

will decide a plan for their On-Prem requirements with the appropriate parties.

3.1.2. On-Prem Migration DB

From XXXXXXXXXX, XXXXXXXXXXX will commence a full SQL Backup of the production DB and restore this to the Migration DB (XXXXXXX) that is located XXXXXXXX.

4. Disaster Recovery Plan

4.1. Failure to Migrate – XXXXX

4.1.1. Failure of Migration from On-Prem to Azure

If there is a catastrophic failure and attempts to resolve this are insufficient to complete the Migration, XXXXXXXX will notify the parties of the Failure on Sunday the XXXXXX.

Failure of Migration Restoration Process

XXXX will communicate to the business the need to access the On-Prem environment at the start of business on

XXXXXXXXXX.

No restoration is required to the On-Prem environment.

A review of the issues encountered and a plan to resolve these issues will be discussed with the parties after the failure occurring.

4.1.2. XXXXXTesting

XXXXXXX will conduct tests to establish that the XXXXXXX CRM Application (CRM) can connect to the Azure environment post migration.

If connectivity cannot be established and attempts to resolve this are insufficient to establish connectivity, XXXXXX will notify the parties of the Failure on XXXXXXXXX.

Failure of Migration Restoration Process

XXXXXXXXXXXXX will communicate to the business the need to access the On-Prem environment at the start of business onXXXXXXXXXXX

No restoration is required to the On-Prem environment.

A review of the issues encountered and a plan to resolve these issues will be discussed with the parties after the failure occurring.

4.1.3. XXXX Testing

IFS will conduct tests to establish that the XXXXXXX CRM Application (CRM) can connect to the Azure environment post migration from all desktops that will be required to connect to XX on XXXXXXXX and basic user activity and reporting is available.

In the event that connectivity, user activity and reporting cannot be established and attempts to resolve this are insufficient to establish connectivity, XXXX will notify the parties of the Failure on XXXXXXXXX.

Failure of IFS Testing

XXXXXXX will communicate to the business the need to access the On-Prem environment at the start of business on

Monday the XXXXXXX.

No restoration is required to the On-Prem environment.

A review of the issues encountered and a plan to resolve these issues will be discussed with the parties subsequent to the failure occurring.

4.2. Failure to use Azure – XXXXXX

4.2.1. Failure of Azure Production

If there is a catastrophic failure for XXXX to use Azure on XXXXXXXX according to the incident identification and priority guidelines and attempts to resolve this are insufficient to complete the Migration, the Parties will meet to agree to implement the Data Restoration Process outlined in section 5 below.

5. Data Restoration Process

STEP 1:

XXXXX to ensure all user disconnect from Azure Production and reconnect to On-Prem Production. Work will continue in the On-Prem environment.

STEP 2:

XXXXXXXX will commence all batch processes conduction up until the restoration occurred.

STEP 3:

XXXXXXXXXXX will commence export of data entered not associated to step 2 and import to the

XXXXXX DB for acceptance testing.

On Acceptance testing XXXXXXXXX will import the data to XXXXXXX. STEP 4:

The parties will meet to discuss the causes of the failure(s) and establish a plan to move to Azure.

6. Incident Identification and Priority Guidelines

This section is provided to help the parties understand and identify what is considered an event that may potentially lead to the implementation of this DRP in its entirety. It is not intended to identify every event but to categorize them for prioritization purposes.

Priority 1 – Critical Impact

Definition

XXXXXXXX cannot be operated causing, or potentially causing, critical business impact to business function(s). In most cases, Priority 1 emergencies fall into these areas:

1. No one can log in to the system.

2. More than half of all users cannot work in the primary XXXXXXXX application due to application fault or environment instability.

3. The application is working, but critical data is unreliable, making further work unproductive. An example might be data corruption caused by database degradation causing an application fault.

Response

Parties will immediately meet to review the event to decide if the issue can be quickly investigated, and the likelihood of a resolution is possible withing an agreed timeframe. If the likelihood of a resolution cannot be established, the parties will agree the restoration process will commence.

Priority 2 – High Impact

Definition

A serious problem exists with the system causing medium impact to business function(s) or customer(s). The effects are not as serious as Priority 1 but warrant investigation as a part of this DRP. In most cases, Priority 2 emergencies fall into these areas:

1. A small number of users are experiencing errors. The situation is serious, but work can still continue.

2. An application error is causing problems, but an alternative procedure is in place.

3. Inability to load new accounts into the system.

Response

If the parties are addressing issues associated to a Priority 1 event, the parties will be made aware that a Priority 2 event is also being reported as the Priority 2 event may be related.

If the parties are not investigating a Priority 1 issue, the Parties will meet to review the issues to decide if these are issues that would warrant the implementation of this DRP or may be a known issues from the Application behaviour in the On-prem environment. If the latter is decided the parties will agree to move the issue to a Priority 3 event.

Where the issue may warrant the implementation of this DRP the parties will decide if the issue can be quickly investigated, and the likelihood of a resolution is possible withing an agreed timeframe. If the likelihood of a resolution cannot be established, the parties will agree the restoration process will commence.

Priority 3 – Normal or Low Impact

Definition

A problem exists with the environment, the application, or the hardware but it causes a low impact to business function(s). In most cases, Priority 3 events fall into these areas:

1. A small number of users is having a problem with their application behaviour that is not present for other users.

2. A user ran a report and did not receive the expected results.

Response

These events are to be referred to the party that is responsible for the event under the usual support agreements.

———————–End of Document————————-

DisasterRecoveryPlan