Using The Database Migration Service

My team has recently completed a migration (or retirement) of 8 Mongo Databases.

Four of them were replaced with lambda functions. (see https://devrants.blog/2019/05/15/replacing-a-mongodb-with-a-lambda/ ).

One of the databases had no data to migrate (the data was transitory and had no value after used).

The last three required the used of the Database Migration Service (DMS). DMS is configured to follow a database and move over any updates to the new system. This allows for minimal downtime when moving from one database to another, especially when taking backups and restoring would be prohibitive.

The DMS is very quick to use (we had a slightly slower approach as we had to use Terraform to configure it and could only start the jobs using a Jenkins task).

One flaw we found was in the error handling. One of our databases (unknown to us) contained some text fields with the null character (\u0000). This is something that MongoDB can handle that DocumentDB cannot. The migrations failed, reporting the error, but gave no clue as to where to find the problem. This was problematic as the system we are migrating has around 2 million documents.

We eventually took a brute force approach to find the problem records:

• Extract each record to a single file
• Read these files and write them to DocumentDB and delete those that worked.

Eventually we found the 40 problem records. These were deleted from the source system and manually inserted into the new.

Eventually we found other problems with DocumentDB that prevented us from using it for the final database (we moved it to another MongoDB provider).

We now have no MongoDB’s on the platform that is being decommissioned.