5 things to remember when migrating to Office 365

office365Many companies are thinking about moving to the Cloud, and this includes SharePoint clients. Microsoft is pushing the advantages of Office 365 to its customers, and many are finding its wealth of features offer a good argument to either move away from existing ‘On Premises’ solutions entirely or set up a hybrid environment which leverages both the benefits from the cloud and on-prem.

There are several advantages in using Cloud systems – including flexibility of functionality, lower start up and ongoing costs, and ease of maintenance. Yet migrating to the Cloud is not always easy, especially when it comes to SharePoint. Many companies still have legacy SharePoint systems which include customizations and lots of content. Not all of these customizations will work in the Cloud, and content migration requires a good deal of proper planning and thought.

Moving to the Cloud can be complex

Migration projects are inherently difficult, and they shouldn’t be undertaken lightly. To test if your organisation or company is ready here are five questions that you should be able to answer positively before attempting an Office 365 migration.

1. Have you audited the current system?

An audit of your current implementation consists of two things:

  • Audit your content: Which content is still valid and which needs to be migrated? Take this chance to delete or archive content that is no longer required in the new system.
  • Audit functionality: Which custom functionality in the existing SharePoint system needs to be migrated? Look at all the options – like farm solutions, custom site templates built using the browser, custom workflows in SharePoint Designer, etc. Office 365 offers new functionality that can often replace custom functionality altogether. Your system will be all the better for using Office 365 native functions as much as it can.

2. Have you audited custom code?

Over the years, it is likely that a lot of custom code has been deployed to your SharePoint farm. If your system has been running for a while you might not even be aware of which customizations are running and even who built them.

It is important to realise that not all customizations can be migrated to Office 365. For example, full trust farm solutions are not supported. Even more you might realize that some of your customizations might not be required anymore or the underlying business need has changed. Thus a re-design might be necessary anyway.

Analysing your customizations manually is extremely time-consuming. Try our our free SPCAF Migration Assessment tool. It generates detailed report about customizations in your farm in a couple of seconds, helps you to understand what they currently do and guides you to migrate them to the app model!

3. Have you thought properly about content migration?

When you know which content you want to migrate, you have to answer the question: How are you going to migrate that content?

Office 365 offers the Explorer View, which allows you to open a SharePoint library in Windows Explorer. This is suitable for small migrations, but lacks certain key functionality like migrating metadata and incremental migrations.

Sharegate is a sophisticated 3rd party option to migrate your content to Office 365, though a number of other products exist. They recently released version 5.0 of their software with a lot of improvements. It will well worth considering a tool like this if you have a lot of content to move.

4. Have you thought about long term maintenance of the new solution?

The implementation of the new solution in Office 365 is a good moment to not only think about the migration, but also about the future:

  • How is content going to be maintained? Will there be a dedicated Intranet Manager or team in place to manage things?
  • How are customizations to be maintained? Even though in Office 365 there is no longer a farm to maintain, customizations need to be monitored and maintained. SPCAF can analyze custom apps and sandboxed solutions deployed to your Office 365 and provide detailed reports about maintainability, code quality, and dependencies.

5. Have you talked to your users?

The most important people in a migration project are the users of the SharePoint system.

By organising workshops with key users, their thoughts about the current and the new solution can be fully understood. Current functionality and content can be discussed and the advantages of new functionality in Office 365 can be demonstrated.

This way users will feel engaged, which helps to increase the popularity of the new implementation. It is generally a good idea to keep everyone in your organisation in the loop as much as possible. Not only by sending emails, but also by organising presentations, demos, workshops, etc. People are key to a good migration.

Preparation is key

A migration project can be complex and requires proper preparation. When a migration is not prepared well, it will most likely fail. Analyze your content and customizations thoroughly, inform and discuss the migration with your users, and develop a migration strategy. Don’t forget to update your users regularly. People in general don’t like changes, so by informing them in advance of change they feel more engaged.

Our own SPCAF can be used to understand and analyze any customizations in the ‘On Premises’ SharePoint environment, as well as migrate and maintain them in Office 365.

Speaking at SharePoint Connect in Amsterdam


I have the pleasure to speak at the upcoming SharePoint Connect conference in Amsterdam about

SharePoint Continuous Integration with VS Online and Azure


With the Cloud Services Azure and VS Online professional SharePoint Development has never been easier.

Having the infrastructure available on demand and only paying per use allows you to build complete production-like SharePoint farms in no time at minimal costs.
VS Online on the other hand provides everything you need to develop projects alone or in a team.
SourceControl, WorkItems, TeamBuild, Automated Testing including the traceability of all of it and detailed reporting.
Even better, with an MSDN subscription both VS Online and Azure is already included.

This session will show you how to

  •  use VS Online to automatically build your SharePoint solutions and apps
  • automatically deploy your SharePoint solutions to the staging farm with VS Online
  • automatically deploy your Provider Hosted Apps to SharePoint Online and Azure

You will receive a 10% discount on the conference registration fee when using my discount code SA336.

If you like to meet up there to talk or to claim one of our awesome SPCAF stickers :) either find me or contact me to arrange a meeting.


Enforcing Good Development Practices in SharePoint

When building out SharePoint systems more often than not some element of custom code will be involved. This is especially true if the requirements are challenging or don’t quite stick to traditional ‘out of the box’ SharePoint behaviour. In SharePoint 2013 this could mean the use of JavaScript, C#, VB.Net, even PHP or Ruby to build customizations.

The quality of these customizations, and the code used to build them, can have a huge influence on different aspects of the SharePoint platform:

  • Security: Poorly written code can introduce security flaws that are hard to detect.
  • Performance: ‘Better code equals better performance’ is so often true. Bad code can have a big impact on the speed of the final application.
  • Maintainability: ‘Spaghetti code’ might get the job done and fulfil the requirements for now, but makes it really hard to apply changes in the future.
  • Stability: Badly written code can have hard to find bugs, which decreases stability and can result in more errors.

In the past SharePoint code could only be deployed as a ‘full trust farm solution’. Microsoft Premier Support, the helpdesk for SharePoint professionals, received more calls caused by badly written code in farm solutions than almost anything else. Microsoft needed a better approach. After the first rather unsuccessful halfhearted fix called “Sandboxed Solutions” they introduced the ‘App development model’ in the latest version of SharePoint. With Apps their code is not run on SharePoint servers, and thus a lot of problems listed above simply can’t occur (plenty of others arise, but this is a different story).

The ‘App model’ permits only client side code (e.g. JavaScript) or server code running on an entirely separate platform away from SharePoint. For example, a SharePoint App can be written in PHP and hosted on a separate Linux server, but then be called from and exchange data with the SharePoint platform.

In any development scenario, even those still using full trust solutions, good development practices are hugely important. This blog post will outline several  strategies that can increase the quality of code in your SharePoint applications.

1. Choose the right SharePoint development pattern

Full trust solutions

Full trust farm solutions are very well alive and certainly will be around for many many more years. Microsoft has committed itself to deliver SharePoint on-premises releases in the future and for some organizations this might the only viable option.
This development pattern we are using now has been well-establish since SharePoint 2007 and is the most flexible and powerful way to customize SharePoint. But with great power comes great responsibility. Too many things can go wrong in full trust world as described in my article “Five reasons to avoid ‘Full Trust’ solutions in SharePoint”.

Nowadays, I avoid them as much as possible and try to find a solution for the business problem with an app, or at least with minimal usage of server side code. By this you can assure that future upgrade of SharePoint or a migration to the cloud will have minimal impact on your code.

Sandboxed solutions

Sandboxed solutions were the first attempt by Microsoft to address the downsides of full trust code. They run in a secure, monitored process that has access to a limited part of your SharePoint farm. Naturally this means also limitations to what you can do with them. Read more about that in the “Sandboxed Solution Considerations” on MSDN. With SharePoint 2013 and the dawn of the app model, Microsoft deprecated the use of managed code in sandboxed solutions meaning that you should only use them to deploy declarative code like content types, fields, list definitions etc.

It is pretty clear that Microsoft will not invest anymore in sandboxed solutions, so rather avoid them if possible.


SharePoint Apps come in two forms: ‘SharePoint hosted’ and ‘provider hosted’. Provider hosted apps are usually more complicated, due to the fact that an external system is involved, but offer a wide range of hosting and coding options. SharePoint hosted Apps are rather straight forward but only JavaScript can be used to write customizations.

It is really important to choose the right pattern upfront, because it is harder to change when development has already started. Microsoft has published an excellent article that should help make this decision easier.

2. Design patterns and methodologies

A wide range of design patterns have been developed and documented over the years. They offer a great insight to the fundamentals of writing quality code. By following a design pattern, code should be more maintainable and readable. The Model View ViewModel is a classic and excellent example, one where logic code is separated from that needed for the user interface.

Dependency Injection and Inversion of Control are also popular patterns and techniques to build loosely coupled systems where components can easily be replaced.

Looking into the brave new SharePoint app world models like ASP.net MVC (Model View Controller) and Angular.js MVW (Model View Whatever = MVV or MVC) seem to have become widely accepted. Still many development scenarios and patterns on top of that, which we got used to do not work anymore, or work differently. Hence, Microsoft and several volunteers of the SharePoint community are providing an Open Source project collecting and refining Patterns & Practises to solve these common problems. I would recommend anyone developing apps to check out their code on GitHub to see if there is already a solution for your problem available that can be re-used.

In general the choice of a model mostly depends on the experience of the developers building the application, but the key thing to remember is that a proper software design will result in better code.

Use a model where one exists and makes sense, but not just for the sake of it. Wise words, I know ;)

3. Implement regular code reviews

Developers make mistakes. And everyone struggles when reviewing their own work. So independent code reviews should be held regularly and made part of the development schedule. They will help to detect and mitigate mistakes, and can be as simple as asking the developer in your team to look over things.

Code reviews can be performed in many different ways eg. Over-the-shoulder, pair programming, tool assisted etc. but, because of the human involvement, they all have in common that they will help you to improve the quality not only from a technical but also from a functional point of view. This is something no automatic code review can compete with as it just does would not understand the purpose of the piece of software (unless you teach it to explicitly).

As a side effect, code reviews help the team to learn from each other building up a common skillset and eventually a more uniform and easier maintainable code.

4. Analyze your code for quality

During development, it is a good idea to use a dedicated tool to analyze code. For example, our own SPCAF will analyze the code against 600 quality rules and generate a report detailing its findings. Fixing the issues highlighted will increase performance, maintainability, and stability and save you lots of time and trouble already before your code is deployed to the production environment.

One thing you have to be aware though is that whichever tool you are using it will never be the silver bullet. A tool can only check against rules that exist and there are always plenty additional practices and errors that could be validated. Also, especially in SharePoint development, many coding practices depend very much on your target platform and your own practices and corporate guidelines.

Let’s just think about the everlasting fight between declarative and programmatic approach in full trust farm solutions. Declaring for example content types in XML was long considered to be the better (though harder to debug) way compared to using a feature receiver and coding the content type in C#. Both approaches have there advantages and a tool can recommend and validate either one, but at the end you have to define which is the better one for you.

Hence tools like SPCAF provide configurable rulesets allowing you to adjust the analysis to your requirements, as well as a Software Development Kit (SDK) to implement your own rules checking your specific patterns and practices.

When you have done that, the tool can help you to make sure you remain consistent throughout your solution or projects.

Making good code even better

One problem with writing quality code is that it is difficult for an outsider to detect the quality between ‘good’ and ‘bad’ code. Bad code might fulfil the requirements, it might do the job in hand, but it could create issues in the future. Bugs could have been be introduced that can affect the performance, and they might not be apparent right away.

At the same time ‘good’ code can generally always be improved. It can be made more performant, can be streamlined, or take advantage of new techniques and approaches. The SharePoint App model is a good example. Lots of full trust farm solutions contain excellent code, written in a professional way, but the App model is still a better future-proof approach.

Either way it is always a good idea to put more effort into design, analysis, and review of code upfront. This way the quality of the code will improve, and so too will the quality of the solution – which is ultimately what everyone wants.

SPC Adriatics 2014 recap and slides

Last week I had the pleasure to speak at the “Probably best SharePoint conference in the world” SPC Adriatics in Zagreb, Crotia.
Being a conference organizer myself with SharePoint Saturday Stockholm, I have to congratulate the team Nenad TrajkovskiAdis Jugo and Toni Frankola to deliver a perfect event which does not have to hide from any other commercial conference I know of.

On the contrary, being a speaker, there has never been and event where I was so well taken care of in regards of accommodation, food, drinks and lots of friends around me. Just awesome! Thank you!

I had the pleasure to talk about two of my favorite topics:

Assuring the Code Quality of SharePoint Solutions and Apps

SharePoint Continuous Integration with VS Online and Azure

You can find the code for the SharePoint solution PowerShell Script I used on GitHub and on the corresponding CodePlex project of the SharePoint Solution Deployer (SPSD).
The HowTo “Deploying Provider Hosted SharePoint Apps to Azure” can be found Kirk Evans’ blog

Thanks everyone for attending! Hope to see you again next year!

SharePoint health check (3): Auditing Customizations

This post is the third of a series explaining how to audit your SharePoint farm.

Analyzing the Customizations

In the previous post we retrieved all code customizations with the help of a little PowerShell script. In order to analyze them,

  1. Go to your machine where SPCAF is installed (SPCAF does not require SharePoint or Visual Studio when analyzing in the client application).
  2. Start the SPCAF client application
  3. Navigate to the network share where you stored the extracted files
  4. Drop one, several or all of the customizations from your farm into the center of your application

    Analyze your WSPs and Apps

    Tip: Analyzing all customizations at once will most likely overwhelm you with the sheer amount of findings, so better only combine the ones that seem to belong together (eg. similar naming, similar source location) as they might have dependencies to each other. Analyze the all others separately.

  5. Click the advanced settings in the client and adjust which rules should be applied, e.g. by selecting an existing or your custom pre-configured analysis settings created with the settings editor.You can also select the different report type that should be created including HTML, DOCX, PDF, XML, CSV or DGML (for dependencies)


    Advanced configuration

  6. Start the analysis and let SPCAF gather the information. This may take a while depending number, size and complexity of the solutions you are analysing.
  7. When the analysis is completed you will be presented an overview dashboard allowing you to navigate into the different results or download the generated report documents.

    SPCAF Analysis Dashboard

    SPCAF Analysis Dashboard

Reviewing the Results

SPCAF will highlight if and where there are problems and give guidance how they can be resolved.

Code Migration Assessment

Code Migration Assessment Report

Its reporting can be broken down into the five areas:

Code Quality

SPCop200x200The code quality analysis validates the code against over 600 rules that vary by severity, the most serious being Critical Errors and Errors. This includes quality rules in categories like Correctness, Security, Best Practice, Localization, Memory Disposal, Performance, Deployment, Syntax, App Store Compatibility and many more.

Note: As it is common with SharePoint there is seldom only one truth. The validity of a many reported violations depend very much on your target environment, the allowed customizations, your internal coding policies and preferences.

Full documentation

Code Metrics

SPMetrics200x200The code metrics can be used to evaluate the complexity, maintainability and migratability of the solution packages and apps. It won’t give a list of easy to follow errors, but it gives a good summary of the structure of the solution helping you for example to calculate migration efforts.
Full documentation

Code Dependency

SPDepend200x200The dependency analysis detects all dependencies between elements in the code and to external components, like references to DLLs, features, JavaScript Frameworks etc.. This can help you to review and improve the solution architecture or to pinpoint missing assemblies or files on your SharePoint farm which causes problems with the solution.
Full documentation

Code Inventory

SPInventory200x200The inventory provides a summary of the contents of the solution. By this you can create a standardized documentation which can be used as reference e.g. when resolving issues found in the ULS logs of the farm, or getting an overview in order to plan a migration to a new SharePoint version or the cloud.
Full documentation

Code Migration

SPCAF_MAThe code migration assessment is a combination of the four analysis view described above, focussing entirely on giving you guidance how to migrate a full trust code solution to the SharePoint app model. It highlights potential road blocks which prevent a 1:1 migration and describes alternative ways to implement a similar functionality.
Full documentation

Seeing is believing so check out one of the sample reports: 

Code Migration HTML DOCX PDF XML

Looking towards a future in the Cloud

Although there is no quick fix to a healthy stable SharePoint farm, using tools like SPCAF and SPDocKit can help start the process. As Microsoft moves ever more to the Cloud, and the new SharePoint ‘App model’ for custom code, understanding how current solutions are structured will become more and more important. We designed SPCAF to help people on this journey, and would love to hear your experiences in the comments below.