The process went fairly smoothly for us, and end users didn’t notice anything.

Our production environment was migrated recently and here are some of the lessons learned we had:

1. Be sure to capture all of your report subscriptions before the migration as we had 2 that just disappeared after the migration. 
2. If you have custom Tabular Models be sure to call that out to the PV team.  We have multiple reports that broke because updates were not made to our custom TMs. 

I cannot update my previous post to adding additional information.  All of our reports that were created with a data source pointing to one of our custom Tabular Models had to be republished. This was done by our team and not the Planview team during migration.  Because one of our reports had 2 report subscriptions built off of it that is why those two subscriptions disappeared.  Once we had the reports republished, thus working, I was able to recreate the report subscriptions as well. 

This was the only issue we ran into with the AWS migration. 

For future reference, when we were migrated, they forgot to restart the job services, so none of our schedules jobs would run.  

Hi -- was there any interruption with Power BI services or odata, if you are using those services?

Thank you!

When ours was migrated we had an issue where our scheduled email jobs using Targeted Subscriptions stopped working.  Something didn’t get mapped over properly.

We have completed the migration of over 80% of our customers hosted in our legacy data centres to AWS. Lessons learned are always used to improve the process for customers yet to migrate.

@johnmarine - we only have 1 Power BI report and did not have any issues with it. 

Thank you!! @pamela.sargent 

Hi John,

We have our custom PBI Planview reports published in the PBI web service and some of our data sets are pretty vast, but no disruption happened during/after the AWS migration. We only turned off the scheduled refresh on that day. 

Only an issue with refreshing the PV out-of-box Resource Management Dashboard occurred after the migration. We still have the ticket open. So, I cannot say what caused it.