How to get your data Office 365-ready - 2

Returning to our analogy, SharePoint is like an open-plan office which you can design in any way you like, whereas Office 365 has rigid walls which you cannot move around at all (we’ll explain why in the next section). While it is perfectly possible to move tables, partitions and equipment wherever you want, it’s generally best practice to stick to the original designer’s plan to avoid confusion. If employees must change their desks around, this request should be submitted to a professional office designer to avoid a chaotic working environment for everyone.

Second, most SharePoint pages contain links to supporting files, including javascript and style sheets, which require additional time to retrieve and execute. Designers can alter the way in which SharePoint pages retrieve these files through a technique called “delayed

loading”, which essentially loads the linked files in the background while the rest of the page is rendering, allowing users to view content without waiting for all the back-end processing to take place. Finally, resist the urge to open SharePoint designer and start modifying the contents of a page directly. This results in the entire page being stored in the content database, from which it must be retrieved each time a user makes a request for it, circumventing the built-in caching mechanisms in SharePoint. Page customizations should be made on a component-level basis whenever possible and leverage common script, file and style sheet resources. It is also a good practice to employ the use of content delivery networks for external libraries (such as JQuery) and images. The above approaches can help optimize page load times and make the move to the cloud easier but in some cases customizations deployed on-premises are simply not compatible with Office 365, where Microsoft reserves the right to change the base user interface components at its discretion. This can cause a great deal of frustration when carefully designed pages suddenly change based on a system update. A good way to avoid this situation is to simply avoid major interface changes altogether and concentrate instead on the modification of content within pages rather than the pages themselves. Revert existing content to out-of-the-box master pages and remove all page-level customizations prior to migration in order to ensure a smooth transition. Then, after the content has been moved to the cloud, revisit those pages where some in-page customizations using the supplied content controls (such as the Content Editor Web Part and Wiki pages) will enhance the user experience.