Migrating to a new version of SharePoint is like moving to a new home.

Before you make that move, there are critical issues to consider. Will the furniture, appliances, and decorative pieces from your previous home fit and work in your new home? What about the custom furniture in your current home that you may not be able to move? For example, it is difficult to move built- in closets that you had a contractor build for you. On a similar note, when was the last time you looked through all your drawers and found just how much useless junk you’ve got hiding in there?

Similarly, a SharePoint migration requires careful planning to identify the critical issues and mitigate the risks of the migration. Whether you’re moving your environment to SharePoint 2013, SharePoint 2016, or SharePoint Online (SPO), it is essential to understand the limits of your new environment, and whether all your content meets these limits. It is also important to consider whether content that is outdated, no longer in use, or forgotten, is worth moving.

It is also important to understand that SharePoint customizations such as custom web parts, custom features and solutions, and custom Master Pages and Page Layouts, do not work in newer versions of SharePoint. Some custom work will be required to move those customizations, especially when the destination is an SPO server, which supports SharePoint Apps and sandboxed solutions.
​
Which is why an analysis of your current environment and careful migration planning can save you time and money, and aid in the optimization of your new SharePoint environment.

​Custom Master Pages, and their associated page layouts, cannot simply be migrated over from SharePoint 2007 or 2010 to SharePoint 2013. While the formatting of Master Pages is similar between these versions, it is not the same, and Master Pages written for one version do not work in any of the other versions.

It is vital to know how many custom master pages you have and what they are, before migration, so that you know which of these you either have to discard, or rebuild to work with Office 365. Once these pages have been rebuilt, you can easily migrate the content directly from the old version of the page to the new version using both the OOTB Upgrade and 3rd party migration tools.

Its best to work with SharePoint UI implementation experts to implement new versions of Master Pages and Page Layouts, and not assigning this task to SharePoint developers, who specialize in a completely different skill set (Visual Studio development vs. HTML and XML) and tool sets (Visual Studio and SharePoint Designer respectively).
​
In addition, i would recommend working with graphic designers to create the look and feel of the Master Pages (usually using Adobe Photoshop® or similar tools), and have the content generated by those tools given to the SharePoint UI implementation experts. Most SharePoint UI experts are not graphic designers, and won’t necessarily create good designs even if they know how to implement designs created by others. Similarly, most graphic designers know how to design beautiful web pages, but are not familiar with UI implementation in SharePoint.

I​n the past, solution delivery was oriented around the waterfall model. Development and delivery of applications was typically divided into many separate steps, such as gathering requirements, writing code, packaging, performing tests, installing the software, etc. Each step was typically owned by one team, which was responsible for only that part of the process, ignoring others.

In other words, developers were focusing only on code development, a process that could last months or even years, leaving solution delivery to the operations teams. New solutions and changes were implemented as one-off revolutions, which required heavy planning and change management processes. This approach had many drawbacks. It didn’t scale well, nor was it immune to quickly changing requirements. It didn’t promote cooperation in solution delivery but promoted competition and blaming others. Any mistake made at the beginning of analysis was stuck with a project until its conclusion, and in most cases entire solutions were
becoming obsolete even before they started yielding any benefits.

The DevOps methodology addresses organizational issues related to the software production process. Since it comes directly from the agile movement, it promotes incremental, iterative solution delivery. DevOps is not about a dedicated team nor is it governed by a well-defned set of rules or tools. 

​Last night was a long one and i was up and about till 2 AM in the morning looking at my laptop screen with amazement and some skeptical approach to the new features been presented at SharePoint Conference 2018 at Las Vegas.

​So here is my post on what was shared and whats coming in future when it comes to Digital Workplace through Microsoft SharePoint and Office 365.

Its been one year since Microsoft Teams was launched and it has been a tremendous success for Microsoft as SLACK is loosing its grip in the market. With O365 and other third party integrations within Teams, its much easier to have a shared chat based workplace  without the need to use different systems. 

I have previously written about How to Get Started, Concept and Usage Scenario and Microsoft Teams Implementation Checklist. Its time to revisit Microsoft Teams and go through some of the fundamental features and capabilities it offers. I am going to highlight each and everyone of those in as much detail as possible so that when you start using Microsoft Teams - you already know your way to get around.

We will be going through the following:

• Clear Out the Confusion - When to Use What
• Introduction to Microsoft Team 
• Microsoft Teams Fundamentals
  • Desktop and Mobile Clients
  • Getting started with Chat
  • Creating Teams
  • Creating a Channel
  • How to Use and Create Tabs in Channels
  • Discovering Connectors and Bots
• Microsoft Teams Adoption
• New and Upcoming Features in Microsoft Teams

​For the past few weeks a lot has been spoken, written and talked about is GDPR Compliance. I have always retained the view that Europeans are much more intelligent when it comes to compliance and regulatory of Personal Data then Americans.  I am not going to use the word privacy because its been the most mocked around word in some quarters and of course in USA we all know how well its protected and implemented. :D

I'll start with first highlighting some key aspects of GDPR - like

​Its not something new and before GDPR we had Data Protection Act so if you had it implemented then you will go through less pain since a lot of elements are partially covered by it. The whole idea and concept is to know how the data is collected, where the data resides, stored, processed, deleted, who can access it and how its used for EU citizens. This means that organizations will be required to show the data flow or lifecycle to minimize any risk of personal data being leaked and all required steps are in place under GDPR.

In short, GDPR is to have common sense data security  ideas, especially from the Privacy by Design school of thought: minimize collection of  personal data, delete personal data that’s no   longer necessary, restrict access, and secure data through its entire lifecycle and also by adding requirements for documenting  IT procedures, performing risk assessments under certain conditions, notifying the consumer  and authorities when there is a breach, as well as  strengthening rules for data minimization.