The Fifth Office 365 & SharePoint 2016 Migration Readiness Pillar: Add-ins
As promised, we’ve reached the final post in our series covering Office 365 migration and what it takes to be ready. In the previous four articles we have looked at architecture, network optimization, database readiness, and branding customizations in what we are calling the ‘The key pillars for migration readiness’.
In our last post we looked at the means in which to customize both SharePoint farm solutions and online, and the issues that you may face.The flexibility of SharePoint On-Premises means organizations that are making the move to Office 365 fail to realize the differences in customization policy. So why the talk of customization? (After all, we covered it in Customizations already). Well, because customization practice in SharePoint On-Premises has been revamped.
In today’s post we’ll focus on the replacement: The SharePoint Add-in Model (formally known as the SharePoint App Model).
Important questions that you need to think about include:
Can your existing customizations be rewritten? Do they need to exist at all or can out-of-the-box functionality in Office 365 replace them?
Does your organization have the staff and expertise to create Add-ins
How are provider-hosted apps to be provisioned and supported? Do you have the infrastructure and web servers needed?
Are you prepared to support the level of remote interaction at the same performance baselines?
These were some of the questions our example company, Lefkada faced in its journey from SharePoint On-Premises to in-the-cloud, Office 365 aficionados.
The role of add-ins in Office 365
Microsoft can’t afford to allow custom code solutions in Office 365 and still be sure of the platform’s performance and stability infallibility. That’s where the add-in model comes in. An Office 365 add-in is a web application hosted in a browser control or iframe running in the context of an Office application. They can access your current data and connect to web services and resources. They perform functions that might otherwise need customized code, but as you might expect, are much safer to build, run and maintain.
On the other side of the cloud
Before its migration, Lefkada used to have a lot of tools that the team was unable to move to the cloud. In an effort to get themselves in an optimal position prior to their move, they put their project team (the same team that evaluated their customized code and content) to work auditing their existing apps, disabling anything they decided they wouldn’t need in the new environment, and for those apps they deemed essential they searched and found the appropriate replacements in the SharePoint add-in store. For apps and tools that they couldn’t replace directly, they explored the options available and decided upon alternatives.
For example, Outlook can often seem to collect a plethora of different customizations over time. Lefkada’s project team evaluated Outlook regarding the customizations that had been made over the years, and filtered out the less used and disabled them before their migration. One of the add-ins the team found that they decided to leave behind was the “You’ve got mail” voice. By going through some basic disabling and uninstalling steps the add-in was no more.
For the customizations that would not translate, they found replacements. As they often need to integrate external SharePoint data in Outlook, Lefkada employed the Business Connectivity Service add-in to help them continue to do this.
It’s hugely important to understand the differences between how your current apps and tools will function in your new environment as opposed to how they work On-Premises. This is significant so that you avoid any unforeseen surprises when you attempt to run your tools, from the first day after migration and beyond. The last thing you want is functionality issues that you are unprepared for, causing downtime and frustration for your employees. Something to be mindful of is that you do have options for building apps in Azure and it is worth developing an action plan to go along with a budget for both building and buying add-ins as required.
To increase your readiness, read our ‘Five pillars for migration readiness’ series here.
Adam is a Director of Product Management at Metalogix and a Microsoft MVP advocating for collaboration by connecting business needs with the right technology. Prior to Metalogix, Adam was a Practice Lead for Office 365 in a cutting edge Microsoft Consulting firm where he was responsible for moving customers to the cloud, designing and implementing information architecture (SharePoint Farm and content) and increasing user adoption. Adam is an ongoing member of the SharePoint Saturday DC coordinating committee and active speaker at various events.