Migration Best Practices with Bamboo Products

Here are a set of best practices we've developed over multiple upgrade/migrations both with and without Bamboo products: 

1. Identify obsoleted content / applications before starting and remove or exclude that content from the migration.
2. Confirm the correct operation of sites and applications before beginning the migration.
3. Confirm the source farm is in good health before the migration.

Bamboo offers Farm Health Check Services to verify this, along with running the install precheck.ps1 (included in newer 18.1 or higher versions) to verify the communication between farm servers by collecting logs.

4. Confirm the target farm is in good health before the migration.

Bamboo’s Services team also can verify this.

Plan on multiple dry-runs of content before the final go-live migration.

5. Plan on multiple dry-runs of content before the final go-live migration.

A test farm to verify data and make sure that applications work correctly is best.

6. Plan on a level of effort to re-mediate issues during the dry runs.
7. Script the migrations as much as possible so they are easy to repeat.
8. If skipping a SharePoint version as part of a migration (for example going from 2010 to 2016), understand that is not a scenario Microsoft or Bamboo directly support – there are some elements that may require extra work on your, our, or Microsoft’s part.
9. If migrating from 2013 or 2016 to Office 365, understand that there is a significant technical difference between the source and target versions that will require extra effort. We recommend that you contact us directly in this case so that we may help. 
10. When making a migration its best not to rename sites or change URL paths.

Any changes to those paths can make the tools break. There may be ways to fix this by  renaming the paths in SharePoint designer.  This is not always possible and not supported by standard Bamboo Solutions Support and would be a Migration Services Engagement.  .

______________________________________________________________________

GOING TO THE CLOUD:

Possible Pain Points to Office 365:
1. Converting any Web Parts client developed to Add-Ins may prove to be difficult.
2. Client built Timer Jobs, there is no real solution when going Online. A work around solution must be found.
3. Event Receivers: a way to host them somewhere, and rewrite them to continue getting the same result they used to.
4. You need to reconsider how you deploy declarative artifacts. You may need to do this using an Azure Web App, PowerShell, etc.
5. Custom Fields should be avoided. Instead, see if Display Templates can help the display content the way you want, instead of creating a new field for it.
6. Depending on migration method, item IDs in lists and libraries will change during the move.