Data Migration: Should You Do It?

If you’ve ever changed from one software system to another, you’ve probably dealt with the subject of migration—the idea of transferring your old data from the outdated system into a shiny new system.

In the case of venue management software, who wouldn’t want that?

Data migration—which may seem like an obvious course of action or even a necessity—is not as seamless, cost-effective, or necessary as one might believe. If not carefully considered, it can actually result in utter frustration and an extremely poor use of your time and money.

The reality of data migration is this: there is almost never an “out-of-the-box” way to do it. Every system has different ways of storing data and mapping information. This means that most data migrations become custom development work, which can be very expensive and time-consuming. With this in mind, it’s important for your organization to think through the goals of such an undertaking and weigh the costs and benefits to your venue.

It’s more than just a matter of having old data instantly accessible—one must first consider what data is actually needed in the new system and why. Here are a few factors to consider:

1. How “good” is the data in your former system?

If the quality of the data in that system yields problems, bringing the problematic data over to a new system would simply transfer the issues (i.e old records, duplicates, etc). Essentially, you’d be paying additional money to encounter the same inaccuracies and frustrations.

2. How often will historical data need to be accessed?

If transferring historical data is a high priority, one must consider how often it will be used and if that justifies the large effort and cost.

3. Will there be access to the old system once the new system is in use?

If so, then referencing the old system might suffice.

4. If there won’t be access to the old system moving forward, will print-outs or archived data be sufficient for historical reference?

The practicality of this depends on how often you would need to reference that archived data.

5. Can data such as client contact information be exported and made more tidy in Excel or a similar application?

If so, a database in this format can be imported more smoothly and cheaply.

6. Do future events need to be imported as well?

If so, there are few better ways to learn the workflow of a new system than to experience the process of entering information into it, especially real information with real value. The need to add future events could coincide with the training process, as part of the instruction would equip staff members to manually do so. Obviously this may not be the most practical approach, in which case the import could be kept as simple as possible—perhaps in the format of a spreadsheet with fields as simple as the event name, start date, and end date.

7. All the considerations above boil down to this:

Will a data migration give your organization a benefit that offers the same value as the time and money it will take? Because a data migration is essentially custom software development, the process can often be long and expensive.

In my experience, we’ve often been asked to migrate “all the data” from a legacy system into ours. But what does that truly entail? Is that the names and addresses of all the venue’s past clients, their past events, every space they’ve ever booked, every napkin they’ve ever ordered and every document they’ve ever sent? Software engineers never design their respective systems with migrations in mind, so there are almost always fields that are nearly impossible to map from one system to another. This is only realized once the technical staff of the new system start comparing the database structures of each.

By knowing what data would and would not be truly helpful, and considering different ways of accessing that data, you can save exorbitant amounts of time and money when switching from one system to another.

When it comes to all-encompassing migrations, almost everyone comes to the table wanting one without knowing what that request entails. But once the cost and benefit is objectively evaluated, very few proceed in the manner they thought they would. Specific discussions reveal there is not as much need for it as initially perceived, and most people realize how cumbersome the actual implementation would be. By taking a more pragmatic approach and analyzing your true needs ahead of time, less time and money can be spent on getting a new system up and running with information that is truly critical.