Demystifying Membership Software Data Conversion

Here are the answers to the most frequently asked data conversion questions we get.

We talk with associations about changing their membership software systems every day. There is, of course, a lot to consider when making this decision: How much does it cost? How difficult will it be to configure? And, perhaps most important, what will happen to our data?

Data conversion and the process of data migration make up one large part of the decision to move systems. While it’s an extremely detailed and carefully monitored job, there’s really no secrecy to it. Quite plainly, the goal is to move enough data into your new system so that when you go live on Day One you see the information you need to see to get your job done; to be able to produce the reports that you need; to be able to follow-up with customers as you need.

FAQs answered in this post:

• • • What data needs to move?
    • Who from the organization needs to be involved?
    • What is the process of data conversion?
    • Who’s responsible for data conversion?
    • How can I best prepare for the data conversion process?
    • How far back should the data go?
    • What happens to the data that doesn’t get converted?
    • What does success look like?

What data needs to move?

Part of our process, starting from the very beginning of the project, is determining what information needs to migrate and how it’s going to be used. While it does vary by organization, ultimately whatever you’ve been tracking in your old system will need to be accessible in the new one. At the very basic level, you’ll want to move information about the people and companies you work with. From one membership software system to the next, you’ll want the same level of CRM data available and accessible. Then you’ll want to bring over information about committees and their activities, and it levels up from there.

The level of detail that we go into varies on how the data needs to be used. Especially when we get into financials, the conversion process can get complex. An organization that carries a large open balance, for example, will have a lot of open accounts receivables and, subsequently, will need to convert enough back history about the money that needs to be collected. You would hate to convert from a system and suddenly lose track of all the information you did or all the bills you need to collect. Identifying the needed data is a big part of the process.

Who from the organization needs to be involved?

Data comes from every department, so people from across the organization need to be actively involved. At the very beginning, they’re identifying data and providing information about where that data currently exists. We’ll get end users involved, who might walk us through screens so we can see how they’re currently using the data. From there, we’ll create the first iterations and then start getting people involved in testing. Different groups get involved in data conversion at different times, but it’s certainly a team effort.

What is the process of data conversion?

Data conversion starts as early as the sales process, where we start talking about the amount of data moving over and how to get prepared for the process. We start out with various iterations where first we’re identifying what source data exists. If the association has an AMS right now, we’re converting data from that AMS. Of course, sometimes there are extra spreadsheets, and other times an organization is running multiple systems that are all being combined into Aptify. We need to get all those sources identified upfront.

Then we start mapping data into the new system. We do this through a process of a lot of small iterations, where we pick off little bits of data and move it into Aptify. This is also a good time to get the users involved so they can start seeing the data in the new system and start testing it. This helps with user buy-in to the new system and gives them the opportunity to let us know if something is missing or if everything’s migrating over correctly. Once it’s working, we’ll pull over the next set. We do this a lot during an implementation and the process can vary from running data conversion a dozen times to running it almost weekly over the course of a year. The data conversion process runs from start to finish. An organization will run data conversion one final time during go-live to ensure all data is up to date during the last weekend before the system fully launches.

From a technical standpoint, we use a data conversion tool that we’ve developed to do a staging process of all the data. That allows us to do validation and to appropriately build relationships between records. That tool then pushes everything into the tables where users will see it in the system.

The data belongs to my organization. Shouldn’t my organization be responsible for data conversion?

Data conversion is central to a successful implementation. As the team responsible for that implementation—and as the experts in the new system—we’ve found that it saves time, frustration, and money in the long run to turn the data migration process over to us. Even the most expert in-house IT department won’t have the experience with the new system like we have. We know where the data needs to go, so we want to be driving this process. That said, your IT team will be actively involved. They’re the experts in the current system and know the data intimately, so they absolutely need to be heavily involved. But the ultimate responsibility for making sure data conversion happens and goes through successfully should fall to the team working the implementation.

This is why we build data conversion into our budget and timeline. Should an expert IT team be able to take over the migration process halfway through the project, for example, then we’ll work with them on getting some credits back. But most organizations find that it’s easier to turn the conversion over to us, let us map the data into their new system and administer testing, and leave it to us to ensure all runs smoothly during go-live.

How can I best prepare for the data conversion process?

Know your system

The process goes much more smoothly when all the data is identified and can be found within the current system. Like anything, this can be easier said than done for several organizations, however. Maybe the current system is a legacy that was developed decades ago and those who built it aren’t around anymore. Perhaps the AMS you’re moving away from doesn’t have an “owner” who understands where the data lives. Or maybe the existing AMS vendor isn’t cooperating with requests about where the data is warehoused. Whatever the reason, it can be hard to get the needed level of expertise on the source data. Any research that can be done ahead of time to find necessary answers will help streamline the process. Work done on the front end will save double the amount when you’re in the middle of implementation.

Clean your data

Just like you spend time doing the laundry before you pack for vacation, it’s advisable to clean your data before moving it to its new system. From getting rid of duplicates to purging inaccurate historical data, you’ll have a tidier set of data to move if you clean it up in the source system.

Identify the workarounds

It’s inevitable: the longer the source system has been used, the more often users attempt to circumvent it. Even when your system is streamlined—which is probably not the case (after all, you are moving away from it)—people will always cheat to find an easier way. And when you try to convert data that’s been cheated, it doesn’t end well. Identifying the workarounds will help highlight future stumbling blocks that can either be avoided or fixed in advance.

Balance the checkbook

It’s easier on the timeline and the budget when open transactions are reconciled before the conversion process begins. As mentioned earlier, open transactions can be moved to the new system, but with them come all the associated historical data. A financial system that’s been fully reconciled can be summarized and transitioned much faster than once that hasn’t.

How far back should the data go?

The quick answer to this is, on average, five years. But, of course, the long answer is that it depends. How useful is your historical data? What kind of organization do you run? Are you operating using old data frequently? The main reason to cut off data has little to do with performance and everything to do with data cleanliness. You want to make sure the data that’s moving to the new system is relevant and up-to-date. There’s no reason to go to the effort of moving data that people haven’t used in years because they don’t trust it.

What happens to the data that doesn’t get converted?

Again, it depends on the data being moved. If your entire data collection is being converted, then, typically, not much of the original data will be preserved—it doesn’t need to be since you’re bringing all your data to the new system. But if we’re converting only recent history or if we’re converting summary-level information for the sake of easing the financial conversion, we’ll keep the existing tables accessible just as they appeared in the old system. These accessible files will now exist in a view, so anyone requiring that data can view it as a table as needed.

Like anything in life, it’s hard to let go of the stuff you’ve had for years. The same goes for your data—there’s some information you’ll want to keep on hand and there’s some you’ll need to jettison. Assess the records you haven’t needed in more than five years and determine if they are useful and should be archived as tables in the new system or are outdated and can be left behind.

What does success look like?

Successful data conversion is being able to go in the system and find the data you need to do your job. This is what we’re constantly testing for. We run business use cases and test scenarios comparing what was done in the old system—”On Monday morning when I come into our system currently, I have to open up XYZ records. I have to follow up with these people. I have these tasks”—and making sure the same can be done in the new. The best test cases are actually clients doing that side by side before we go live. The goal is hearing, “OK, I did this in our current system. And then I did this in Aptify. And I got the same results.” That means the data was correct.

How do you select the right membership management software?

Download the IT Checklist for Evaluating Membership Management Software Vendors for factors to consider and questions to ask.

Get the checklist.