Migration Center of Excellence

We’ve converted many years of project and migration experience to a standard and proven methodology that helps organisations with the migration from a legacy DMS to Microsoft 365. 

Terabyte Migrated

Different Legacy Systems

%

Aligned with Microsoft Best Practices

Years of Migration Expeirience

Migration Toolkit

Transform Data’s Migration Toolkit accelerates the extraction of information from legacy systems and has a
standard way of packaging and importing information to the new SharePoint Online, Microsoft Teams or OneDrive for Business location. This includes the migration of meta-data information such as the modified date or author of the
documents, which makes it easier for users to get used to the new system.

Migration methodology

With over 100 successful projects, mostly with legacy document migrations from various systems, We’ve developed a standard and proven methodology that helps organizations with the transition to Microsoft 365.

Our migration experts are familiar with various legacy systems that are commonly used in legal, corporate legal, accountancy and financial services and know what specials should be taken into account during migration.

 

Armstrong Watson

Type: Accounting & Consulting

Legacy System: iManage Work

 

Migros


Type:
Corporate Legal Department

Legacy System: WinPat

 

Norsk Hydro


Type:
Corporate Legal Department

Legacy System: iManage Work

 

Boels Zanders Advocaten


Type:
Law Firm

Legacy System: iManage Work

 

AkzoNobel


Type:
Corporate Legal Department

Legacy System: Passport

 

1. Migration checklist

Our migration always start with an intake to fully understand your source system. This can be a structured DMS like iManage, NetDocuments, Virtual Cabinet or a more open format such a a filesystem. Either way, we need to understand the logic behind the source. What level of folders reflect a matter or a client for example.

>> Download the iManage Work Migration Checklist

2. Mapping & rules

Once we understand the source structure, we can discuss and build the rules and mappings. This allows us to either migrate “as is”  or to apply translation or aggregations logic into our migration.
(For example: we often migrate personal workspaces to users OneDrive instead of company SharePoint or Teams locations).

3. Read source

We will typically read directly from the source system (database and filestore, or via API connection), so we would never adjust or update your existing DMS. It will remain untouched until you are comfortable to switch over and eventually turn it off.

4. Test migration

We typically do a test migration trying to cover data from all the
types of work, all the practice areas and all the different types of workspaces. We then typically have a broad migrated data set
available for examination during the test phase of the project.

5. Bulk migration

Are you happy with the test migration? Then we move on with
the bulk migration. We migrate the history documents (often millions of documents) over to Microsoft 365, using Azure Storage for maximum throughput and performance.

6. Delta migration

Once bulk migrations has finished. We do the delta migration,
to detect and copy over the differences since the last (bulk) migration. This can be done once, if you prefer to go at once with
all users or multiple times if you prefer to have the go-live in groups.

7. Reporting & fixing

While our migration software has a very high success rate, there will always be exceptions, like that one document that cannot be copied. We would report on those and fix these manually, so we make sure nothing is left behind.

8. Optimise documents

Lastly, we can improve documents which can be done for example by adding OCR-text layers, to improve search results. Or by adding additional metadata such as knowledge tags, to provide extra functionality to end-users.