Planning and executing the migration

Key objectives when migrating from the old system to Omega 365 is to ensure that all documents, meta data and user permissions are migrated successfully migrated with at least possible downtime and disruption to the organization and projects.

These are the main steps we recommend when migrating.

1. Assess your  documents, data and access: Identify which documents that needs to migrated, and which meta data that are relevant to keep when migrating. Evaluate the need for "cleaning up" in existing data and documents before starting the migration; identifying duplicates, outdated or irrelevant documents that can be removed or archived. Understanding the legacy system's security and access model is important to ensure that there are no issues when migrating the data; e.g. are there confidential documents, who has access to these etc.
2. Identify how to technically migrate the documents: The data can be exported from the existing system in Excel, CSV or similar format, or if available, one can use the legacy's system API's. The files can be transferred by regular file transfer, using safe ftp protocols or similar. Which method to use depends on the infrastructure, where the existing system's data and documents are located.
3. Data mapping and structuring: Map the data fields and structures in the old system to fields in Omega 365. Identify the need to use of the custom fields. Document groups and types are essential as these are used both access control and configuration of functionality. Many of the fields in Omega 365 have so-called foreign key constraints, meaning that only pre-defined values are allowed, such as document types and discipline codes.
4. Develop a migration strategy. Depending on the amount of documents and data, the migration may be broken down per project or per asset, or all documents and migrated in a one-go. Alternative is a "rolling" approach, where one first migrate all "dead" documents - such as old versions and revisions, and archive. Then only the delta needs to be migrated when going live in Omega 365. A recovery plan should be prepared. Note that the longer one has been live in Omega 365, the more complex it is to back-out, and go back to the old system, as a data migration from new system to old system normally not would be a part of the scope.
5. Perform a test migration: Migrate documents and data. This could be the whole set of documents, or a relevant subset of documents and data. Verify that documents are transferred, meta data correctly mapped. And that user access is migrated as agreed. Adjust the migration procedure as needed. The client's and key users must be highly involved in this process, as it is their data and documents and therefore have a good basis for determining if the transfer has been successful.
6. Execute the migration: Based on the migration strategy, begin transferring data from the old system to Omega 365. Monitor the process lose to ensure data integrity, accuracy and completeness. The old system should be set to read-only during the final migration to ensure that all data are migrated into the new system. 
7. Hyper-support: Ensure that the client gets access to pro-active and fast-responding support during the immediate period after migrating. Even if the users are well training
8. Decommission the old system: Once the migration is considered successful, the process of decommission the old system should data. Ensure that backups are made, and kept for a period, just in case issues with migration are identified later.

Preparation

To estimate the work involved in the migration the following documentation / information should be provided from the client:

• Procedures for document management, especially related to document coding
• The scope for migration
• Where the data is stored (e.g. migrating from existing Azure data centers eases the migration process)
• Which system(s) to transfer data from
• The consistency in usage (e.g. a global standard vs project specific setup and configuration)
• Examples of data extracts

Key risks when migrating

Migrating from an old document management system to a new one carries certain risks. It's important to be aware of these risks and plan accordingly to mitigate them. Here are some key risks associated with such a migration:

1. Documents or data loss or corruption. During the data migration process, there is a risk that data are not mapped correctly, data fields ignored in the migration scripts. It is crucial to have backup available, and do a well structured verification process, so that corrections can be made both before going live, and immediately after.
2. Downtime and disruption: The migration would typically require limited access to the system for a period. Carefully select the timing, e.g. execute it during weekend or low-usage periods. Going live in a more quit period also makes it easier to deal with issues that are identified after going live.
3. Security vulnerabilities: Migrating data from one system to another can introduce security vulnerabilities if proper security measures are not followed. The old system may have a very different access control system. Ensure that access is migrated and implemented as agreed with client. Conduct a thorough security assessment and consider data privacy and compliance requirements throughout the migration process.