Project checklist for records management systems migration

This guidance relates to: Stage 1: Plan for action Stage 2: Define your digital continuity requirements Stage 3: Assess and address risks to digital continuity Stage 4: Maintain digital continuity

This guidance should be read before you start to manage digital continuity. The full suite of guidance is available on The National Archives’ website. Project checklist for records management system migration

This guidance will help you prepare for migrating information between Electronic Document and Record Management Systems (EDRMS), Enterprise Content Management (ECM) or Content Management Systems (CMS), or from one to the other.

Note: all records management systems will be referred to as EDRMS for simplicity.

This step-by-step checklist will help you manage your project and work through each stage of your system migration. It will help you to manage the migration of your information in a way that maintains digital continuity.

If you are using Agile project management methods to deliver the project, you can access extensive guidance and community support on gov.uk.

Project initiation and planning

☐ Define high-level aims and objectives for the project ☐ Define success criteria ☐ Establish project structure and management processes ☐ Establish project governance and expert project management support ☐ Identify resources (skills, budget, testing, etc.) ☐ Establish a cross-disciplinary project team ☐ Liaise with suppliers ☐ Identify risks and issues, such as: • Are objectives and success criteria sufficiently clear and measurable? • Have they been agreed at the appropriate level? • Are governance and reporting structures appropriate? • Have adequate resources been allocated? • Are the right skills available? • Are external suppliers engaged?

Define requirements

☐ Identify what information is affected Establish how the business needs to use the information

Consider whether migration is the right approach

Identify what information to migrate

Define detailed digital continuity requirements, such as:

- What content, context and provenance information do you need so that you can use your information as required?
- What do you need in order to be able to find, open and work with information as you need to?

Communicate your usability requirements to the wider project team

Specify the functionality you need from a new EDRMS

Develop test criteria based on the requirements for the information, such as:

- Criteria for categories of information or information with different owners
- Criteria for content transferred to an archive environment that may be less demanding than for content transferred to another organisation
- Capabilities of the destination system may influence test criteria

Agree ownership of requirements and test criteria

Identify risks and issues to the migration, such as:

- Does the information owner understand business requirements in sufficient detail and have the ability to judge whether the information meets these requirements?
- Are there constraints in the technical capability of the originating and receiving EDRMS?
- What would be the impact if the requirements for the information change after the transfer has taken place?
- Have you established clear owners for the information before and after migration and identified whether you need to make any changes to the business process for managing information subject to migration?

Develop, test and implement a solution

Note: development of a solution should be undertaken off line from the production system before being carried out on live systems.

Agree responsibilities for developing and testing a solution Assess export capabilities of the source system:

- Export schema
- Data volumes
- Export performance

Assess import and export capabilities of the destination system:

- Import and export schema
- Data volumes
- Import performance

Assess compatibility:

- Does the export contain all the required information?
- Can the required information be accommodated within the destination system? (Consult the metadata definitions for the source and destination to do this mapping)
- Does the destination system support the required functionality?

Identify data transformation(s):

- What transformation is required to make exported information suitable for import?
- How can this be achieved?
- Can information missing from the export schema be captured in another way?
- Does the data transformation fully meet the specified requirements?
- Document what will be missing from the migration, if anything. Evaluate whether you need to retain the originating system for longer, because of this

Define migration process:

- Formalise the process for export, data transformation and import, including relevant system settings and any manual steps

Define test criteria based on functional requirements

Test migration process:

- Test the migration outside the production system(s)
- Test using representative data and data volumes
- Test that imported data meets requirements • Refine process if necessary and re-test

☐ Define deletion process: • If required, develop and test a process for deleting content from the source system, leaving a marker in place if needed (for example, if you are only migrating partial information from the EDRMS and it is remaining in use, you may need to document where information once was)

☐ Identify risk and issues, such as: • How will the export process impact the performance of the source system? • Can the exported data be adequately protected? • How will the import process impact the performance of the destination system? • What are the risks to source and destination systems? • Can a failed or partial transfer be rolled back?

You need to test your original requirements against the knowledge you have built up: • Can the migration meet all the requirements? • What are the risks to the business of any loss of continuity? • Is the test process sufficiently rigorous to provide an assurance of continuity? • Do the requirements need to be amended in any way? • Do the achievable benefits outweigh the costs? • Does the business case need reviewing? • Can you mitigate the risks you have identified? • Have any new risks emerged?

Carry out the transfer

☐ Agree responsibilities for carrying out the transfer

☐ Agree timing for the transfer: • Consider impact on both systems • For Machinery of Government (MoG), coordinate data transfer with formal transfer of ownership

☐ Carry out the transfer according to the defined and agreed process

☐ Identify risks and issues, such as: • What are the risks to source and destination systems? • Can data be adequately protected during the migration process? • Can a failed or partial transfer be rolled back?

Test for continuity

☐ Test migrated information ☐ Evaluate test results and assess whether migrated information meets requirements ☐ If information does not meet requirements, identify and manage issues: • Refine and re-test the migration process, and repeat the transfer. This approach may have cost and time implications, but it is necessary if migrated volumes are large or the information has significant issues • Fix the migrated data within the destination system. For small-scale issues, issues with medium impact or issues where no alternative remediation is readily available this may be quickest and most cost-effective approach • Accept issues with migrated data. This may be appropriate if the issues have low impact and alternatives are not readily available

☐ Involve users of the information in the acceptance testing process ☐ When migrated information is of an acceptable quality, confirm receipt of content within the destination system

Delete content and decommission redundant systems

☐ Identify risks and issues ☐ Agree timing for the decommissioning ☐ Securely decommission redundant systems according to the defined and agreed process

Finally...

☐ Update Information Asset Register (IAR), policies and procedures to reflect the new location of your information, allocating new information owners if appropriate