You're almost at the end of your data migration journey!
Before we can call this project done, we need to check the final boxes to ensure everything is in place for a successful migration.
Migrating to Production
Once all requirements have been met and the new system has sign-off from stakeholders, it's time to go to prod. Moving all solutions from your development environment to production is the first step in enabling end users to move their day-to-day to the Dataverse. At this stage, you should have all of your business processes and applications copied over to the Dataverse. If you have existing canvas apps for Power Automate flows that reference your existing SharePoint data, those will need to be copied and pointed to the Dataverse tables. This can take some configuration, but following the training section, you should be equipped with the tools and knowledge necessary to make this happen.
Final Data Migration and Validation
After your Dataflow(s) have been imported to production via solution, it's time to run them to bring your data into prod. There needs to be a cutoff time when end users will (ideally) not be working in the legacy system so there is no data lost while migrating. This time should be communicated to all end users so they know when the legacy system will be cut off and the new system will go live.
After your data has been imported from SharePoint, it's time to check to make sure no data was left behind. This can be done quickly by checking the Modified timestamp on active SharePoint lists and comparing it to the data in SharePoint. You can also re-use the PowerBI report from the validation stage to check all records and make sure the number of records in production matches SharePoint.
Final Go/No-Go Decision
There should be a team of stakeholders and developers that make the final call to proceed with the implementation at this point. Everyone should have time to do all final testing before pushing out the production system. If anyone gives a no-go then the developers should take away all new requirements and complete them in development, then import to production. Another data import will need to take place before more testing to ensure all production data is updated.
Once everyone votes to go through with the migration, you're officially live! End users should start utilizing the new system, while their access to the SharePoint system is restricted in a reversible manner to accommodate any potential need for a rollback. These Lists can eventually be archived or deleted if necessary.
Post-Go-Live Support and Monitoring
You should expect issues as end users come online to begin using the new system. Whether these are simple UI/UX questions that naturally arise when users begin to use a different system or unforeseen issues that were missed during testing, something (or multiple things) will likely come up. You should have a plan in place for multiple support developers to be on standby for go-live. If you are a smaller company with one or just a few devs, you can reach out to a consulting company for support hours to make sure everything goes smoothly.
Backup and Rollback Plan
Similar to typical support, you should have a plan to roll back changes if something drastic is wrong. It's impossible to plan for what may go wrong or when at this stage, as any known issues should be fixed. You and other stakeholders should have a discussion to gauge the tolerance of problems you are willing to address during go-live.
I would recommend that tolerance be fairly high.
There should be a very short generalized list of items that trigger a rollback, as rolling back can cause data loss.
If the threshold for a rollback for your company is low, I would recommend creating Power Automate flows that can automatically roll new and modified data back to SharePoint from Dataverse.
Another option would be to run both systems in parallel for a few hours/days before giving the go/no-go.
Documentation and Knowledge Transfer
There should always be a handful of people who at least partially understand the migration process for this system. There should be at least two people who understand the migration in its entirety. During go-live, after all requirements are satisfied and all outstanding changes have been made, I recommend recording a knowledge transfer meeting where the primary owners walk others through the new system.
The migration at this point is practically done, so knowledge of how it works may not be necessary to document further.
The beauty of the Dataverse and the Common Data Model is that it's fairly self-documenting and easy to walk through.
The main customizations to document would be granular or buried objects such as calculated columns, business rules, and JavaScript/Plugins if those apply. If you are unsure what those are, then you likely don't have any (these were not covered in this series).
Recording a deep dive session is usually the fastest and easiest to consume for of system documentation. To do this you can simply hop on a Teams call and record the meeting.
I hope this guide was useful in explaining the process of migrating from SharePoint to Dataverse in detail. If you have any questions, please leave them below.
Comments