We have started to use the FileMaker data migration tool to upgrade our clients to the latest version of our solution and it works so much better then our past workflow. But now we are wondering just how much confidence we should have in the tool.
In the past we would do a full check of all fields for all records to make sure our transfer went smoothly. This is a time consuming task and one we would love to skip. But with past method of importing one table at a time we did at times find situations were data would change.
Has anyone had any issue with the FileMaker data migration tool causing any issue? So far in our tests we have not been able to find any but we have only used it three times so far. My hope is that no one has and that will give me confidence to limit our check to just a few key fields sooner.
There's at least one situation you need to work around (or at least had to in the past): Claris Community (English)
But overall I've had no other problems with the data integrity.
It's not a bad idea to maintain a script that verifies the integrity of your data, which you can run after updates though, especially when updates contain scripted custom transformation logic. It can check things like "no orphan child records in this table", "all records in this table have x field set" etc.
The data migration tool is one of the best things Claris has ever released. We use it weekly to upgrade clients' systems.
The only issue we've had was web direct reverting to US date formats after an upgrade to a clone of a UK formatted file. This was overcome with the introduction of the -locale file after reporting the problem in the community. Other than this it has been rock solid for us.
Can you speak more about how OTTO? It is something we have looked at but I am not sure it would help us based on our size and frequency of updates. We also have issues with different clients still being on different version of our solution.
Otto automates all the various steps that go into DMT, plus providing a fall back position.
There are a few steps to install Otto, well documented on their site.
Let's see if I can get the various steps that Otto uses defined - been a year since I dug into it; it just runs.
Pre-requisites:
One or more production databases on N number of servers
A Development database
Changes to migrate:
List item
Code, Layout, etc .... ALL edits made to the dev copy
Open OTTO and pick a configured migration, to manually run, or scheduled
Otto then - all automagically ......
Clones the dev copy
Copies it to the targeted production server
Closes the production file, renames, and moves it to another directory
Migrates everything from the production copy to the cloned dev copy, with file names you specify
You can push to N number of servers all at once from a single source (if you have multiple solutions with identical code)
As far a different versions of FMS - the same care should be taken in confirmation as it is with DMT natively.
Another great alternative is FMDataMigration from Lesterius.com. This is an excellent wrapper for DMT; extremely well implemented, highly configurable, and...... free. Kevin Vanderbrande created this most excellent tool. You can configure N number of one to one server migrations. Unlike Otto, you have to make the clone file and get it into the right location. But just the reporting aspect of what goes on under the covers, is an invaluable education. I love how easy it is to "fill in the blanks" and not deal with the arcane syntax of the DMT command line. Solutions - Lesterius
We just launched Devin 1.0 for Linux last week, with macOS coming soon
(and windows is back on the feature request list Windows Server support | Voters | Devin)
