The FileMaker Data Migration tool (FM DMT) is a great tool that helps developers conduct deployments. To learn how to use the FM DMT, check out our video here: FileMaker Best Practices: The Data Migration Tool.
After using the FM DMT to migrate data from one file to another, it is a good practice to check the summary at the end to spot issues.
Sometimes, we will find a certain number of tables or fields not migrated. Don’t panic! This article will discuss identifying which tables and fields are not migrated and what to do afterward.
Run the DMT in Verbose Mode
If the previous run was not in verbose mode (with the -v option), do the DMT again, but this time, turn on verbose mode. This will generate a much more detailed migration log that will tell us what worked and what didn’t.
See the sample command below. Note the “-v” at the end, indicating it will run in the verbose mode this time.
FMDataMigration -src_path "SourceFile.fmp12" -src_account "source account" -src_pwd "source password" -clone_path "CloneFile.fmp12" -clone_account "clone account" -clone_pwd "clone password" -vAfter running the DMT in verbose mode, I suggest copying the detailed log out of the command line tool and into a text editor for easy search.
Identify Tables Not Migrated
The easiest way to find tables not migrated is to search for the phrase “No target found for source table.” This should help you locate tables in the source file, but not the target.
Note that sometimes after performing recovery on a file, FileMaker will automatically generate tables named “Recovery XXX.” If you have performed recovery on your target file, it might cause these recovery tables not to migrate, which is not a big deal.
Data schema changes might result in tables not getting migrated, such as deleting tables in your target file but not in your source file, and creating tables in the source but not the target.
Identify Fields Not Migrated
The easiest way to find tables not migrated is to search for the phrase “No compatible target.” This will help you find fields in the source but not the target.
To see which table this field belongs to, scroll up until you find the closest “ == Mapping fields in source table XXXX. “
Data schema changes, such as deleting fields in your target file or creating fields in your source, are the most common reasons for fields not being migrated.
What to Do After Identifying Tables/Fields Not Migrated
We want to identify these tables and fields to determine whether they hurt our migration/deployment. Long story short, not all of them are bad. What we are looking for are things we didn’t expect.
Some changes will naturally cause tables and fields not to migrate. For example, if you intentionally delete a table or field in the target file, it’s completely normal to have that table/field not migrate from the source. However, deleting a table or a field is a rather big change. Be sure to use your DDR to do reference analyses and ensure that deleting this content won’t cause a problem for your app.
On the other hand, you might find things you didn’t expect. Perhaps you find a table added to the source file by some developer, and due to miscommunication, you never knew about it. These surprises should warn developers to clarify the situation and possibly consider halting deployment, rolling back, and rescheduling deployment.
One important lesson I learned (the hard way) is that in most situations, it’s better to call for a rollback and reschedule the deployment than try to “tough it through” and do massive troubleshooting on the day of the deployment.
What Can I Do to Avoid Surprises?
As a rule of thumb, if there are deployment-related activities we can do before the actual deployment, we do them before the deployment. We want to plan, test, and rehearse before the day of deployment to remove as much uncertainty as possible.
Suppose I’m facing a very important deployment (for example, some organizations require their FM app to have a very high uptime. So the downtime we need to do deployment could be very costly for them). In that case, I will do a dry run by going through the deployment procedures minus uploading the migrated file to the production environment. During this dry run, I would have used the FM DMT for data migration. So, if there were any potential surprises in there, I would have found them before the actual deployment and had plenty of time to deal with them.
I hope this article can help you troubleshoot or, even better, prepare for smooth deployments.