Lets admit that migration of any sort is a pain and migrating something to the cloud for the first time is always challenging. I have been going through this for quite some time and finally had the chance to play with Azure Migrate and it has been a good experience overall.

​If you plan to go to Azure you will have 2 choices for your current environment:

• Recreate you infrastructure from scratch
• Use Azure Site Recovery to “move” your on-premise VMs to Azure

The goal of this post is to explain you what is Server Migration and how it can help you for your migration to Azure.

​The Azure Migrate service assesses on-premises workloads for migration to Azure. The service assesses the migration suitability of on-premises machines, performs performance-based sizing, and provides cost estimations for running on-premises machines in Azure. If you’re contemplating lift-and-shift migrations, or are in the early assessment stages of migration, this service is for you. After the assessment, you can use services such as Azure Site Recovery and Azure Database Migration Service, to migrate the machines to Azure.

Azure Migrate helps you to:

• Assess Azure Readiness: Assess whether your on-premises machines are suitable for running in Azure.
• Get Size Recommendations: Get size recommendations for Azure VMs based on the performance history of on-premises VMs.
• Estimate Monthly Costs: Get estimated costs for running on-premises machines in Azure.
• Migrate with High Confidence: Visualize dependencies of on-premises machines to create groups of machines that you will assess and migrate together.

​I recently created a Microsoft Office 365 development environment via https://aka.ms/offdp

I was creating an environment to do some SharePoint Modern theming (I created a new Communication Site via the modern Admin interface on my new tenant), but noticed the classic (rather the older) Change the Look interface:

When you create a new Office 365 group, there will be an associated SharePoint Team site is created automatically. In this case, we need a new Group with an existing team site. To start with, make sure connect to Office Group is enabled at tenant level.

Login to SharePoint Online Admin Center >> Click on Settings from left navigation. In settings page, under "Connections from sites to Office 365 groups", Set "Allow site collection administrators to connect sites to new Office 365 groups".

Now, you can connect your SharePoint Online sites to Office 365 groups. To connect an existing SharePoint Online site to new a Office 365 group, follow these steps: 

Login to SharePoint Online site collection with Site collection administrator rights >> Click on the Settings gear icon >> Select "Connect to new Office 365 group". You are now presented with overview page about a quick explanation of what will be created by Office 365 for your site collection what's going to happen by connecting your site to an O365 group. Click on "Let's get started"

We all know that Get-SpoSite cmdlet contains more than one parameter set and you may only use parameters from one parameter set and you may not combine parameters from different parameter sets. Moreover, it retrieves and returns properties of all site collections that match the given criteria.

But sometimes you run into weird issues when you are doing the most common things. In this case, one of my friend was cleaning up his demo Office 365 tenant.  To make an overview of all site collections, he ran the following cmdlet:

​This would make a list of all site collections that are available in  Office 365 tenant and export it to a CSV file. When going through it, he noticed that none of the site collections were flagged as a hubsite. This couldn’t possibly be true as  he created many hub sites for testing purposes.

I decided to check this in my own tenant to see if it was a local problem. So let’s see what happens.

​Running the following PowerShell returns all site collections that contain the word intranet.

​Since ASP.NET Core 2.2 was released I have been working on getting all my different applications updated and using in-process hosting. I pretty quickly hit an issue with an application that uses SQLite. As soon as the application tried to access the database I ended up with the following error.

After some Googling, I found an issue on GitHub that details the problem. It turns out that when the application gets its current directory it is returning the path to the IIS process that is hosting the application instead of the directory when the application is.

On another GitHub issue, I found a link to a recommended workaround. Add the following class somewhere in your application. This code comes here.

Given the diversity of operating systems supported by Docker and the differences between .NET Framework and .NET Core, you should target a specific OS and specific versions depending on the framework you are using.

For Windows, you can use Windows Server Core or Windows Nano Server. These Windows versions provide different characteristics (IIS in Windows Server Core versus a self-hosted web server like Kestrel in Nano Server) that might be needed by .NET Framework or .NET Core, respectively.

For Linux, multiple distros are available and supported in official .NET Docker images (like Debian). In the image below  you can see the possible OS version depending on the .NET framework used.

You can also create your own Docker image in cases where you want to use a different Linux distro or where you want an image with versions not provided by Microsoft. For example, you might create an image with ASP.NET Core running on the traditional .NET Framework and Windows Server Core, which is a not-so-common scenario for Docker.

When you add the image name to your Dockerfile file, you can select the operating system and version depending on the tag you use, as in the following examples:

I have come across this issue of Date and Time  in SharePoint that i feel like writing an email to Microsoft for making this the most confusing thing ever . 

When you create a Date column you have the choice of Date and Date & Time.

Note the keyword “Format” in that option. Even if you select “Date Only”, your users can still type, or copy and paste, a date and a time and it will be stored as a date and time. But… only the date will be displayed.

After considerable amount of wasting my effort and countless guess work, i came to understand that Times are represented as parts of a day.

You should use .NET Core, with Linux or Windows Containers, for your containerized Docker server application when:

•  You have cross-platform needs. For example, you want to use both Linux and Windows Containers.
•  Your application architecture is based on microservices.
• You need to start containers fast and want a small footprint per container to achieve better density or more containers per hardware unit in order to lower your costs.
  

In short, when you create new containerized .NET applications, you should consider.NET Core as the default choice. It has many benefits and fits best with the containers philosophy and style of working. An additional benefit of using .NET Core is that you can run side by side .NET versions for applications within the same machine. This benefit is more important for servers or VMs that do not use containers, because containers isolate the versions of .NET that the app needs. (As long as they are compatible with the underlying OS.)

You should use .NET Framework for your containerized Docker server application when:

•  Your application currently uses .NET Framework and has strong dependencies on Windows.
•  You need to use Windows APIs that are not supported by .NET Core.
• You need to use third-party .NET libraries or NuGet packages that are not available for .NET Core.

Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This “lift and shift” scenario is important for containerizing legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps or WCF (Windows Communication Foundation) services.

Plenty of people have written on this topic and  i'll try to clear out some misconceptions about how you should go about it. Moreover one needs to draw a very clear line about Migration and Upgrading since they are both different which a lot of people seem to mix up. On a lot of forums i see people asking questions like how do we migrate from SP 2007 to SP 2013 and then to 2016?  Another question which is quiet frequent relates to SharePoint 2010 license and if its possible to do a direct migration from SharePoint 2007 to SharePoint 2013.

The issues can be resolved easily and it is not that difficult as it looks like. You only need to go through the post with full attention. So, let us get started.

Oftentimes, it happens with the users that they are currently using SharePoint 2007. But, as the advent of new features and technology, they think of SharePoint to SharePoint migration. Although, it is believed by many users that it mandatory to switch from 2007 to SharePoint 2010 and then, further proceed towards SharePoint 2013 migration. However, it is not true. This post deals with the best possible solution for moving from SharePoint 2007 to 2013 and also gives a chart to show the benefits of SharePoint 2016 and why you should consider it.

I have written very extensively on the topic of Migration to SharePoint Online, in case you are looking for it. 

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.