Kristi Webb is a Senior Consultant at ThreeWill. She has over 18 years of software development experience working on software solutions and integrations for enterprise and product solutions. Her passion is applying technology solutions to solve business problems and improve efficiency.
Two-Pass Approach to Migrating
For Jive migration customers that are moving large amounts of content to Microsoft 365, we typically complete a two-pass approach to migrating where all the content is migrated in the first pass and then verified for a period of time. Once validation is complete, we complete the second pass/delta migration and capture any new or updated content quickly to complete the migration process by the planned end date, usually just before a go-live for the Microsoft 365 sites. Most customers with large amounts of content items prefer this two-pass approach since it allows the business users to access and update the content in Jive with the least amount of disruption.
We recently had a customer that was migrating their Jive content to Microsoft 365 and realized a critical need to consolidate several Jive places together into one SharePoint site after we had already started the production migration. This consolidation included moving several content items from other out-of-scope Jive places into Jive places that were in-scope for migration. On top of that, this also included moving personal blog posts that were originally out-of-scope for the project into in-scope Jive places.
A Potential Issue
Our Delta or second pass migration traditionally captures all new additions or updates to the content items within a specific Jive Place by looking for brand new content items in the place and updated content items where the updated date in Jive is now greater than the last date the content item was migrated to SharePoint. During testing, we noticed several moved items were not flagged as new or updated items for the delta migration, so we investigated the issue.
We learned that moving a content item from one place to another place in Jive is not considered an actual ‘update’ and the update DateTime value is not changed in Jive after the move, although the content item’s parent place has changed. The moved items were not considered new items by our tools since they already existed in our migration database from an earlier inventory related to the original Jive parent place. Interestingly, moving a content item from one Jive place to another does keep the same content-id or unique identifier.
We adjusted our process to not just rely on the update date, but also check if the parent place has changed, so the moved content item and all its supporting binary files (attachments, images, etc.) would get moved to the new SharePoint site properly. If the content items have related comments or messages, these also get pulled into the new Jive place.
These code changes to our Jive to Microsoft 365 migration tools now ensure that content moved in Jive to new place locations are migrated properly to the new SharePoint site(s) during the second pass or delta migration, and this is a great example of how we are constantly improving our Jive to Microsoft 365 migration tools to adapt to our customer needs. We had a customer that needed to consolidate content and capture personal blog posts after the two-pass migration had already started and we were able to make it happen.