I have not had problems with imports. Tables are Tables, and FileMaker is very forgiving about data types
The hard part is clicking thru the old solution, to see what it does ( and if those features are still useful )
If you miss a feature, users will scream
> exporting from one and importing to the other will be a job in itself and fraught with unexpected hazards and surprises.
I've done a similar transition in the past with a client and my best advice is to check, double check and triple check.
What i mean by that is to do a few dry runs of the import. What looks fine in their current program may not transition well into FileMaker without massaging the data beforehand.
I helped convert from a user from their messy FM solution to my neat FM solution. The saving grace was doing scripted imports. I had set these up as migration scripts and imported into duplicate tables in my solution, done data manipulation and cleanup in the dupe tables, then I did another import into the final full working tables of my solution. This insured that I could track where problems could have happened in the conversion and data migration and let me fine tune the whole thing.
I would also make sure that your client's original data is properly characterized and cleaned up e.g. you'd be surprised how many people put text into a number field or a date field. Make sure that's considered in your migration
1 of 1 people found this helpful
In additional to fully scripting the imports of data into the various tables, I would script in any data tests at each import level to be sure you are dealing with the bad stuff that gets into almost all data systems.
Taking a copy of the live system and actually trying to import each into a table in FM is an essential step in the prep process so that, when the time to transition from old to new-FM, the process is quick.
I generally plan to shut down an old system at end of day Friday and install the new one early Monday AM. That gives me the weekend to manage the data transfer and cleanup, and I try to get it all done on Saturday. If the imports and cleanup are scripted, that generally works out fine, though the size of the data tables can be an issue. (I've worked on systems with so much old data in them that importing a single table into FM ran for several hours back around FM10 when pullling via WAN!) You really want to have all the data on a local machine for the data migration.
I often create a completely separate data migration tool in FileMaker to do all the data massaging. This tool will contain a mirror of the tables in the final FM solution, along with any "worker bee" tables that are needed for the migration. It allows me to experiment, experiment, and experiment some more on the incoming data stream before importing it into the final solution. And, it allows you to put all your migration scripts into a completely separate database so they don't clutter up your actual solution. (And yes, I agree that scripting is very useful.)
I also agree with Stephen - do your migration on a local machine, then load to production. You really don't want to spend hours doing an import, only to discover a mistake at the end of the process. :-\
Thanks everyone, these are very helpful suggestions. I can tell I will have my work cut out for me though. I'll have to do research into the concept of data migration tools... importing tables is as sophisticated as I've gotten so far.
Another thing to consider is what you are moving from, what output formats you have available (some proprietary systems don't like to give up their data nicely), and also will your table structure / ERD be basically the same, or are you making structure improvements? For instance, are you taking something that was more "flat" and making it more normalized? That makes the imports more complicated, but makes the end product much more powerful.
My best advice, based on very limited experience, is to create an interim file that as closely as possible matches the structure of the existing nonFM file—rather as you would have if you simply opened a spreadsheet with FM. This gives you a copy of the original data but importantly it is now FM data, so you can better compare like with like and perhaps spot issues more easily. So this halfway file is (1) a facility to help you pick up on issues you may face with the existing data itself; (2) a resource file you can use to devise methods to address such data problems; and (3) the source you will use for the final transfer of data into the new FM solution. You will have to reimport the data from the old file ultimately, as while you have been working on development of the process preumably the old file is still in use, but by then you will have developed the transfer process. I imagine that what I have described reflects much the same thinking as others have already outlined (especially Mike's "completely separate data migration tool") but sometimes reading the same general ideas in different ways can help get one's head around ideas.
I do something similar.
Definitely operate locally.
I use a "third" stand alone file with a table for each table in the source data and a table in each of the target filemaker file with all the same fields named exactly the same as their counterparts. Makes matching up for imports easy.
You can script the import into the middle file, using scripts to split up/combine (usually split up) rows. The target fields should be calcs doing data manipulation if necessary referencing the source fields of the "mid" tables even if it's just =to their partner.
You'll also want scripts that clean out the stand alone file since you'll be running test imports over and over again until you get it right.
The hardest part will be the final transition. Unless the client are okay with doing double entry, which they're usually not, you've got to do the import perfectly while they're sleeping. I'd recommend doing the import to test and having clients use the test for a few days to make sure it's all working before doing the final import.
my client will need to transition from their current, badly-suited software, to my FMP solution - but as seamlessly as possible and without losing important data now stored in the old software.
It sounds like you have gone past this but you should make your first, second and third question: why not keep the old system?
Reasons to keep the old system: They own it. It is installed. It contains their data. People are familiar with it.
Reasons to dump the old system: ??
Do these reasons outweigh the disruption to established systems and the learning curve to use new ones?
It is really important to establish this upfront. It helps the client to come to grips with what they are doing and why. In extreme cases, it saves everyone a lot of effort. We recently had someone tell us that they needed a new system because the old one didn’t allow them to search for names in the contacts module. It was a filemaker database! We spent a couple of hours training them and they’re happy.
I'm wondering if there are any "best practices" or general approaches that others have used when having to do this. How do you transition your client from their current system to your shiny new Filemaker one, as painlessly as possible?
Prepare your clients for that fact that your solution is not a mimic of their old solution. Make it extremely clear that it is new software and it will be completely different.
Get them to write down what they want the new solution to do. If you don’t have it in writing, signed by both of you, you are going to suffer. After weeks of discussion about requirements and functions, when you hand it over, people will say, for example, “but my old system had a purple patch in the corner!” At that point, reach for your co-signed agreement and ask them to find that item in the list of specifications.
1 of 1 people found this helpful
Aside from the technical aspects of transitioning from one system to another you should consider developing a transition plan (google it and youll find a wealth of hits). IMHO training is vital to successful adoption of a new system and is not limited to teaching functionality. Users that are enthusiastic adopters of a new system usually are outliers not the norm and you've got to have patience with the user base backed with management support for the new system.