Hacker School gGmbH is currently moving its entire organisation to Microsoft Dynamics. We are supporting the project step by step, and an important part is now complete: fundraising has moved from Salesforce to the new environment.
What sets this project apart: the data migration was only the second step.
What Dynamics does not bring along
The fundraising team works mainly with grants. Each grant comes with funders, a funding period and a set of deliverables tied to it. Anyone on the team who wants to know what is due next for which grant needs exactly these links.
Dynamics does not offer these processes out of the box. Contacts and organisations can be created straight away; a grant with a term and obligations towards the funder cannot.
Why not just move the data across
The shorter route would have looked like this: export from Salesforce, import into Dynamics, done. The grants would then have landed somewhere: in note fields, in repurposed standard fields or in a spreadsheet next to the system. On day one the team would have worked with a system that does not know their work, and found workarounds.
A migration moves data into a target model. If that model does not exist yet, the import decides what it looks like. That decision belongs to the people who will work with the system afterwards.
How we went about it
- Design the grant logic. Together with the team we worked out how a grant is structured for them and what depends on it. That became the model in Dynamics.
- Implement and test. We built the model in Dynamics and ran it through test cases.
- Agree it with the team. The team tried the system before any real data was in it. At this stage a change costs little, because no data depends on it yet.
- Migrate. Only once the foundation was in place did we move the data from Salesforce, straight into the matching structures.
The result
- All grant data migrated completely and cleanly.
- A system fitted to the way the team works.
- A team that has worked productively with it from day one.
What we take away
A good migration does not start with the data export but with the question of how people want to work afterwards. For a CRM switch, that means for us: first build the target system so it fits the work, then move. How we set up projects like this in general is described in Advise, implement, operate.
Thank you to the team at Hacker School gGmbH for their trust and the collaboration. We are looking forward to the next stages.
When you do not need this
If your new system already knows your processes, for instance because you are switching between two solutions of the same kind, a clean field mapping is often enough. And if it is only a few hundred records that need cleaning up anyway, retyping them is sometimes faster and cheaper than a migration project.
Where grants, donations or other processes are involved that a standard CRM does not know, the order pays off.