You’ve gone through discovery and you have a solution. You’ve worked closely with your consultant to flush out any requirements and you’ve validated that the build looks good and your system functions as it should. The next step is a doozy though – the data migration. You have sent over the data and have set a date for when the migration is going to happen. The data is clean, the data map has been signed off, and you’re ready to go. But there is one more change that you need to manage before the migration begins – the DATA FREEZE!
What is a data freeze?
It’s exactly what it sounds like. It’s a time when you tell your data to stop, put its hands up and FREEZE! No new records. No changes to existing records. No updates of any kind. It’s a scary time in a project, but necessary for data integrity.
When does a data freeze occur?
A data freeze will occur when you start your data migration. It’s during the transition time between when you hand the data off to the data migration resource and when you are live in your new system. Migrations are usually scheduled for Monday morning, so it’s a good idea to freeze the data on the Friday afternoon before the migration begins. Then you will have time to take a snapshot of your data and send it over to your consultant before the weekend starts. It’s necessary because you’ve given the data set to the resource to import into your new system, so any changes that you make after that hand off will not get transferred into your new system.
How can I manage my data freeze?
As with any aspect of the project, communication with your team is essential for the data freeze to be successful. Make sure that your whole team knows what is happening well in advance of the actual cut-off date. Make sure they know that they need to get all the updates in before the cut-off date. Also, let them know the replacement process in place during the data freeze to enable them to act accordingly. As with the other parts of the project, if a user is not told what is happening, they will come in on Monday morning and continue using the old system like nothing has changed. Confusion is frustrating and we’re trying to minimize frustrations during this process.
Even though you aren’t entering new data, it doesn’t mean that you can’t access records. You can read records, run reports, and look up information. You just shouldn’t be changing anything in your old system. If you change a record in the old system after the freeze, that change will not get brought over into the new system and you risk having data discrepancies.
- To manage the freeze, it’s a good idea to change permissions for all end-users to Read Only. This way they can’t unintentionally make changes, but they can read records and get information.
- Make sure that all integrations are turned off. For instance, if you take online donations that are being fed directly into your old system, make sure that that integration is turned off.
- It’s a good idea to check a report after the first day of the freeze to make sure there aren’t any new records being created. Maybe there is a trigger that is firing that is creating records without your knowledge. If you do find this to be the case, let your project manager know immediately.
What do I do with new data during the freeze?
Different organizations handle this in different ways. One suggestion is to keep any new data in a separate spreadsheet, which can then be used to enter data manually into the new Salesforce system, after the data migration is complete. This will work if you don’t have that many records coming in on a daily basis.
If your volume of incoming data is large, you may consider using a tool like Apsona or the NPSP Data Import Wizard to mass import records.
If you don’t feel comfortable with importing the data from the freeze yourself, we can explore a ‘Delta Migration,’ which is a second import of data once you are live in your new system.
No matter which way you choose, make sure that it works for all of your teams. If the development team can’t handle the incoming donation information, but the program management team will be fine using spreadsheets, then a solution needs to be explored to handle the different teams. Keeping all teams in mind during this transition is going to be key for success.
Not having a system to input information can be scary, but it’s temporary and necessary. Making sure that all users know what’s going on and having a backup plan for your data is going to make the migration process smoother and easier for everyone. Keep in mind, at the end of it all, you’ll be in your new system with ALL of your data.
Other posts about the data migration process that may be helpful include:
Moving House: Steps for a Successful Data Migration
Nonprofit Starter Pack (NPSP) Data Importer Tool Deep Dive
Data Migration: Apsona for Salesforce
