9 Months of Fun with SharePoint in Azure and Office 365
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,433 views
My whirlwind experience migrating SharePoint for a customer with no it department into the cloud.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 9 Months of Fun with SharePoint in Azure and Office 365
Ähnlich wie 9 Months of Fun with SharePoint in Azure and Office 365 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
9 Months of Fun with SharePoint in Azure and Office 365
- 2. My Background • 18+ Years in Technology • Today: Office Servers & Services (Office 365) MVP and Independent Consultant • Previously: 12 Years Developing Software, IT Infrastructure Projects, Workflows, & Other Related Topics • B.Sc. in Comp. Sci. from the University of Victoria (BC, Canada) My Social Channels Blog: itgroove.net/mmman / Twitter: @MMMan_Colin
- 3. • I spent 9 10 months working on a SharePoint migration project • Migrated SharePoint sites from parent company to divested child company • Sites were destined for both SharePoint on premise (living in Azure) and SharePoint Online (Office 365) Or, more simply put… ** Lessons Learned **
- 4. • Major Pharmaceutical company • New spin-off company (We’ll call them “New Org”) • rhipe Solutions (the company I did this work through) • Several Other Contractors
- 5. • New York, NY, USA (rhipe Solutions office) • “Beautiful” Parsippany, New Jersey, USA • Parsippany has a lot of pharmaceutical companies located within and around it
- 6. • Migrate SharePoint 2010 & 2013 sites to SharePoint 2016 & SharePoint Online • No “on premise” IT (no server room) • A few parallel projects
- 7. • Originally just a 4 week contract (July, 2016) • Turned into a 10 month project (July 2016 – May 2017) (question asked by the wife often)
- 8. • New Org was able to utilise the parent company’s IT resources for a temporary period (ending EOY2017) • New Org needed to establish all their own IT services and applications before the above deadline • Office 365, Azure, as well as SharePoint all fell within the above parameters • Personally Identifiable Information needed to remain “on premise” (not under someone else’s control) • Complex workflows & custom applications also needed to remain “on premise”
- 9. • Setup Production farms and import DB extracts from parent company directly into Production • Maybe push some content into Office 365 (using a tool?) • Original design called for ~12 farms & ~46 servers to control ~100GB of anticipated content
- 10. • After test content was provided, adjusted expected size became at least ½ Terabyte of data • Introduced a Staging farm • Used Metalogix Content Matrix to move content to SharePoint Online and Production farms • This approach allowed us to move ~80% of all content into Office 365, and only required us to keep a minimal amount of data on premise
- 11. • Migration of data only – No Intranet • Branding (both on premise and SPO in Office 365)
- 12. • Parent company • A lot of politics & opinions led to some bad decisions • Trying to be helpful and friendly can backfire • Lack of knowledgeable IT staff caused major delays
- 13. • Could not have direct access to the source SharePoint sites / content • Getting details about the source SharePoint farms was next to impossible • Access to knowledgeable staff in regards to the custom applications was also exceedingly difficult
- 14. • Not all staff were cut over to New Org’s new devices • As such, we required a temporary Azure Application Gateway to expose on premise SharePoint to those individuals who did not yet have a New Org device (laptop) • Managed Metadata had to be removed in order to prevent files from being checked out to the migration account on the target
- 15. • Things for the most part actually went really well • Staging farm approach worked awesome • A solid QA team really helped mitigate issues • Permissions were a challenge, because of the approach • The custom solutions were more challenging than anticipated • Final numbers were in the ¾ - 1 Terabyte of data range
- 16. • Nintex had several issues • Not enough testing of custom apps prior to migration • Long window of downtime
- 17. • Not all tools are created equal • InfoPath is no longer Office 365 friendly (new sites) • Azure based server builds should be scripted
- 18. • Small Team = Good at most times, less good at others • Development Migration Requires Special Skills • You can’t fix stupid / inexperience (in a single project)
- 19. • As my contract came to an end, there were some remaining open items • All remaining items were passed over to a pair of colleagues
Hinweis der Redaktion
- Started with Interviewing
- I did come home for xmas Worked remotely from Australia for 3 months
- Self contained dev and staging farms (AD forests)
- Softlayer vs Azure debate raged on for far too long New Org PM team was eradic PM’s were mostly useless Couldn’t ever seem to agree on Change Orders Licensing of 3rd party components (such as Nintex) took ridiculously long – everything was a major headache trying to get it through purchasing AD can be very challenging and tough decisions need to be made early. For the sake of progress, we made some difficult decisions about employees vs contractors, but the security agent wanted to change everything later in the game. It was a foolish decision on their part, IMHO The staff on my team was great, some of the other folks were amongst the least qualified IT staff & PM’s I’ve ever seen
- Things like getting the source Managed Metadata was like pulling teeth. SharePoint depends on this stuff, and although the eventually provided it, it was only from a single farm, and they refused to tell us which one it was from