Taking your CRM to the Cloud in one hour

This is and edited version of my talk at Microsoft TechDays Stockholm 17 november 2016.

Do you dare to go from an on-premises CRM to cloud based solution to gain all the benefits from the cloud? Developing and deploying you CRM solution for the cloud doesn’t have to be impossible or costly. If you plan it carefully, follow best practices and sprinkle it with a bit of ingenuity it’s hard to fail. It is possible to lower your cost, increase quality, get more automation, and have full control in the cloud. In this session, we will look at one way to manage your CRM transition to the cloud.


I just want to say that when someone dares you, usually you should not pay any attention. You shouldn’t even pay any attention if someone double dares you… You know what? Someone double dared me once, and somehow I accepted the challenge. A couple of months later I was running my first ultra-marathon in the Swedish mountains.

Some quick notes before we really start

It is hard to talk about one specific topic without touching on another, closely related topic. So, bear with me when some topics bleed into each other.

Microsoft rebranded Microsoft Dynamics CRM to Microsoft Dynamics 365 a couple of days ago. So, bear that in mind. I will use the term CRM, Microsoft CRM, and Microsoft Dynamics CRM.

In this talk I will ask a lot of questions that I don’t have the answer to. You are the ones that must answer these questions, whether it is in your own business or if it is in your customer’s business.

This session is a level 100. Actually, I figured out that it is really hard to do a level 100 talk, because one should expect that the audience have any previous knowledge about the topic. So, I’ve done my best to keep things simple, but this talk is more like 175 than 100…

We will have time for questions at the end.

Do you dare to go to the cloud?

So, do you dare to go to the cloud? So, I just said that you should ignore anyone saying that. So, lets change this so that you don’t ignore me.

Do you dare to stay out of the cloud?

A typical scenario is that it is time to upgrade/install/move your CRM solution. You’ve decided to go with a on-prem solution. You should just go ahead and insert the CD to start the installation, right? How hard can it be?

Install and setup the server, install the CRM software. Create your business rules. That would be something that an Enterprise Architect and a Solution Architect could do in a couple of weeks, right?

Yeah, and don’t forget that the CRM needs a database to store everything on. It should be installed on a fast server with lots of memory and processing power.

And you must integrate your CRM solution to your Active Directory, and you should have your Identity provider installed so that you provide a Single Sign On solution throughout the organization.

And don’t forget about backups.

And security, your system must be secure.

And redundant storage.

And we have all these tools and 3rd party solutions that should integrate towards the CRM. Do we have to invest in a new integration platform? Will the one we just deployed cope?

Business Intelligence; we should have all that so that we could track our user’s behavior.

And all the machines to handle that load.

And we must connect to our online service thing. Which is in another part of the network. So, we must setup an DMZ to separate the services. Secure you know.

And we should have a solution for logging

And monitoring

Load balancing is necessary

And you have some users that want to access the CRM solution from outside the office. Using a mobile device. Typically, an IPhone…

You must have trained people to handle all this operational stuff. If only I could hire enough people to handle all this technology.

And you must keep an eye on the cost. How do you keep track of all the money spent on infrastructure, man hours, licenses, training, operations and so on?

TCO of On-Premises vs Cloud

TCO of On-Premises vs Cloud

This is a simplified figure to show that there are a lot of hidden costs with an on-prem solution. To the left in this figure you all see that above the surface there is cost of software licenses. But below the surface, hidden from our view, are the capital expense for customization and implementation, hardware, head count, maintenance and so on. Operational expenses are also listed under ongoing costs.

To the right in this figure you see that over half of capital expense when deploying to the cloud are subscription fees. The other fixed, up front, costs aren’t there. The ongoing cost, or operational cost, are much smaller because that is part of the subscription.

Do you still dare to stay out of the cloud?

Ok, so you’ll continue with your on-prem installation and deployment. You’ve got your system up and running and it is time to open it up and let in the users.

During the project, you must make predictions on how the system will be used. And it is pretty hard to do these predictions. How many users should it be able to handle? What is the expected load? How will the underlying infrastructure handle everyday usage of the system? Have you tested and planned for all use cases?

But, you decide to open up your system. Then this happens.

This image shows what happened when Niantic launched Pokémon Go in Australia and New Zealand. And, you all might agree, this is an extreme scenario. But it is useful for proving my point that you have advantages of being in the cloud.

The orange line in the figure is Niantics Original Launch Target load. That was the estimate that they had. Just to be sure they also had a Estimated Worst Case scenario with 5 times the load. Just in case something hit the fan, they would have some extra capacity, The green line shows actual number of transactions. It took roughly 15 minutes to exceed Estimated Worst Case.

Looking at this figure one sees that they did their predications and forecast, or guesstimate if you rather want to use that word. They also calculated with a worst-case scenario. But I don’t think that they could have foreseen what would actually happen. This is proof that they couldn’t.

In this case, they worked closely with Google to solve the problem.

A more realistic scenario is something that we experienced after a go live. It was at a customer running an cloud solution. The customer experienced performance issues in the web api that we’ve built in front of our CRM solution. The requests sent from the web app, through the api, towards the CRM took longer and longer time to return. We couldn’t find any performance problems with the code. The solution in this case, and in the case of Niantic was to scale the environment that hosts the solution. This is done without affecting the daily operation of the service. For us the problem was solved in a couple of minutes once we had ruled out software problems.

But, what do you do when you are running on-prem and you hit the roof within a week, a month? How do you handle a pressure on the system that you didn’t/couldn’t foresee? I think the answer is: You can’t, not fast enough at least.

“It is difficult to make predictions, especially about the future” -Clever Danish person

So, this is a word of wisdom that I usually keep in mind. ”It is difficult to make predictions, especially about the future”. But with this cloud this isn’t really a problem. Because the effort of adapting to current conditions are small compared to running an on-prem solution.

Go to the cloud!

So. My message is: Go to the cloud! You have to go to the cloud. Your competitors are going to the cloud. I don’t think you can afford not going to the cloud.

Your answer to my dare should be: I don’t dare to stay on-prem, I am going to the cloud.

Who am I?

My name is Mikael Hallne. I work at Kentor. My role varies from Software Developer to Systems Architect to Technical Project Manager. But no matter which role that I have I tend to preach/nag/whine/rant about testing, quality, coding standards, a continuous mindset, sharing is caring. Promoting the agile mindset. So, I always end up with a bigger responsibility in the project than first intended…

Long story short; I’ve been involved in a couple of projects where we’ve transitioned from an old CRM to a new Microsoft Dynamics CRM solution. Both on-prem and transitions to the cloud. I don’t know that much about CRM itself. But I know a few things about making it work in the cloud, and how to integrate services towards it and so. So, this is based on real world experience.

Why should you go to the cloud?

So why should you go to the cloud? Whether it is part of your corporate strategy and in your long-term plan, or if your company or customer are just curious, here are some of the benefits I see for going to the cloud. And, I guess you’ve heard quite many of these over the last two days.

It is a low entry barrier to get started in the cloud – It is really easy to get started. A couple of clicks. Some code. And you are up and running.

It gives you flexibility – It gives you the opportunity to scale your environment on demand. You turn the control knob, and you increase the power. You turn the control knob the other way, and you decrease the power.

With a low entry barrier and flexibility you can be agile – You can setup a new environment in a couple of minutes to a day, instead of months when hosting the infrastructure and solution by yourself. You can test your ideas. You can fail fast, try many solutions, and in the end, use the best.

Being agile leads to shorter time to market. It might be a couple of days from idea to implementation instead of months if you host your solution yourself.

Being in the cloud gives you better control over cost – The cost of your system is collected on one invoice that you’ll receive every month. And you pay for what you’ve used. You don’t have to spend money in advance for something that might add value in the future.

It reduces your TCO of infrastructure – You don’t have to have a capital expense in infrastructure. You don’t have to buy new servers, and invest in datacenters. That leads to less pain during maintenance as you don’t have to manage updates of your system.

It gives you reliability – The cloud vendor has SLAs that promises you uptime. You also got load balancing, data replication and so on to ensure reliability of the system.

It gives you security

It enables easy monitoring and lets you gather metrics

The cloud also enables you to use a continuous integration and delivery pipeline. It is there, it is cheap, it is easy to use.

The Cloud makes sure that you don’t outgrow your system.

What is The Cloud?

The Cloud is an giant Internet based “resource pool” accessible from everywhere. And it gives you the possibility to use what you need, when you need it, with a minimal management effort, using a “pay as you go” model.

As I said in previous slide, the Cloud gives you:

Scalability/Flexibility – Scale on demand

Agility and short time to market

Reliability, Redundancy, Security

Iaas vs PaaS vs Saas

The cloud usual offers three different service models:

Infrastructure as a Service

Platform as a Service

Software as a Service

You have on-premise to the left. You manage everything from networking, storage, servers, virtualization, operating system, runtime, and so on.

With infrastructure as a service you get your infrastructure in the cloud. For instance, a virtual machine that you’ve got complete control over. The service provider manages networking, storage, servers, virtual machines and so on. You manage the rest, from operating system, runtime, and up to applications. So, you are responsible for keeping your system up to date. It feels like an on-prem machine, but instead of having it in your data center it is in the cloud. That is, the service that you use and pay for are infrastructure. This is a perfect service if you want to move an existing on-prem application to the cloud without doing any changes to it.

We’ve typically used Infrastructure as a service when we’ve set up FTP servers, or we set up an virtual machine with an SQL server that we got full control over during data migrations. Or we have virtual machines running Team City or Octopus Deploy. Or imagine a startup that can’t afford to own this much hardware. And they cant afford daily operations to have this service up and running. Instead they buy their infrastructure as a service.

Platform as a service provides you a bit more than Infrastructure as a Service. You also get an Operating System, Middleware and a Runtime. You might also get development tools and so on. That is, a PaaS gives you a complete development and deployment environment. You need to manage the application, and then let the application execute in the platform provided. That is, the service that you use and pay for are the platform needed to run your application. Azure, Google App Engine are examples of a Platform as a Service.

We usually use platform as a service when we host web applications, web apis, we run azure webjobs there, we use it for identity providers, and all sorts of integrations towards the CRM.

With a Software as a Service solution the service provider manages everything. The service provider manages the hardware and software, and with the appropriate service agreement, will ensure the availability and the security of the application and your data. You manage the content. That is, the service that you use and pay for are software managed by someone else.

Examples of Software as a Service applications are web based email such as Gmail or Hotmail, Dropbox for storage, Trello, or Dynamics 365 that Microsoft offers.

Hybrid solution

Just a quick mention of hybrid solutions.

Simply taking something that used to be on-premises and making it run in the cloud is of limited value. There isn’t a 1 to 1 mapping between an on-prem installation of the CRM and Dynamics 365 (CRM online).

You might have much of your existing infrastructure on-premises. Or you might be reluctant to use some key applications in the cloud. There are many ways that CRM Online can operate as part of a hybrid IT solution. Using CRM Online doesn’t mean the you have to move your whole IT stack into the cloud.

A hybrid solution offers you the possibility to not have to choose between on-prem or the cloud. With a hybrid solution, you can integrate your existing environment (on-prem that is) with the public cloud (Azure for instance). So, the cloud works as an extension of your current environment.

You need a strategy

Ok, so now you’ve made up your mind. You are going to the cloud. You are going to “lean in” as Brad Anderson said at the keynote yesterday. Or, your customer has decided that they wants to take on the cloud. So, it is your job to help them to lean in. And you are bringing your CRM system along on the ride. But, before you start anything, it is important to have a strategy.

I’ve joined projects that’s been running for a couple of months that were lacking a proper strategy. Without a real strategy, everything is hard. The strategy is part of the foundation of the project. It is a real struggle to try and finish and deliver a project that’s lacking a strategy. We don’t know when we are done. We don’t know what we are going to achieve. We really miss the fundamentals of what we are trying to achieve.

So, in my experience you need a well-defined strategy to start with. But, you also need a roadmap. Once you’ve got the strategy, you can create a roadmap, which is more detailed and hands on.

In the process of creating the roadmap we start to ask questions like:

  • Will we do IaaS, PaaS, or SaaS? A mix of them all?
  • Are we going to just move existing solution, i.e. do a 1 to 1 mapping of existing functionality into the new solution? Or are we doing a rebuild?
  • Are there other systems in our existing IT solution that could or should be moved to the cloud?
  • What opportunities do we have to modernize the solution?
  • What opportunities are there for innovation?
  • How do we design our solution for it to really take advantage of the cloud?
  • How will we handle data migrations?
  • What we do here are laying the foundation for future work. From these questions and the answers provided one can start to create high level requirements or epics and start to get a sense of what needs to be done.

At this part in the project, it is also an excellent opportunity to decide on testing strategies and whether to do continuous integration/deployment or not. Hint: you should go for as much automated testing as possible and you should do continuous integration/delivery!

As part of your strategy and roadmap you should decide on if you are going to do a pilot deployment? One with a limited set of data and functionality used by a limited set of users? That way incrementally introducing the new system and new functionality to the business? Or do you want to do a big-bang deployment where you switch from the old system to the new one with a large data migration?

Indiana Jones


So before a big bang release, you feel nervous for when is a good time to do the switch? Will it work? Have we done everything? The business is nervous. People are afraid of switching. Everyone hesitate.

You all know what happens when Indy does the switch right? Everything looks fine for a while. Suddenly a large rock comes tumbling down, he runs for his life, screaming and panicking. You do the connection between this and a big bang release…

But, as you all are aware of the IT industry likes to think that it is agile. And some companies are. But not when it comes to delivering a system, then suddenly it is traditional waterfall with a big bang release in the end. So, part of your strategy should be to deliver agile, with a pilot and adding value incrementally.

Considerations before moving your CRM to the cloud

Ok, apart from creating the strategy and the roadmap, there are some other questions that you’ve got to ask yourself. These questions are more the ones that drive your design. And these are only a few of all the questions that you’ve got to ask yourself.

Will all your services in the cloud be in for instance Europe so that you comply with the Data Protection Directive (PUL) (or the new General Data Protection Regulation effective around 2018)?


Microsoft updates their CRM system twice every year. You don’t really have the choice of not updating, you can only postpone it for so long and you can only skip one update. If you got version 8.0, and 8.1 is released, you can skip that one if you want to. But once 8.2 is announced you are forced to update your system to 8.2. How do you handle that? How to make sure that your system is built to handle that? We will talk about best practices in a while.

When you are in the cloud you have to design for the cloud. Microsoft CRM instances use a pool of shared resources. This is a key difference from on-prem installations, as this means that no portion of these shared resources are dedicated strictly to the instance running your solution – they’re shared. That means that you must design your solution to accommodate potential scenarios where these resources don’t perform your requests immediately.

If you or any of your neighbors, in the cloud, sharing the resource are using an excessive amount of resources, you may have a governor placed on your usage. That might lead to strange errors if your solution isn’t designed for the cloud.

And, as I said, these are all some considerations needed before going to the cloud.

Drawbacks of being in the cloud with your CRM

Are there any drawback of going to the cloud? Of course there is!

What you gain in flexibility, you might lose in control. For example:

You don’t have control over your servers. As mentioned earlier, you share a resource pool.

You don’t have the same control over the SQL-servers. You have problems tweaking the servers’ performance. If you for instance want to add an index to improve performance you have to contact Microsoft support. We’ve seen that this is and issue from time to time. It is solvable, but it is time consuming and frustrating.

You are not 100 % in control of when to update the system. We have a customer that didn’t want to update its system because they were in a business-critical phase during the autumn. We chose to postpone the update. The message we got was that we choose when to perform the update, we are in control. All of a sudden this new version is announced, and we can’t postpone the previous update any longer. We are forced to update during the most critical part of our customers yearly invoice period. I had quite a few calls with Microsoft to try and postpone that update.

You don’t have full control over your data in the sense that it is located on someone else’s computer

You don’t have full control over your data in the sense that you don’t have direct access to the database so that you can query it the way you want to

And as Brad talked about yesterday, you don’t know who is accessing your data.

Are you sure that the cloud service provider is transparent enough so that you can see where your data is stored and how it is secured?

Best practices

Ok, so you’ve decided to go for an online, Software as a Service, solution. What do you do next? One of the things you should do is to follow best practices, or patterns and principles as Microsoft call it. There are a lot of benefits following them.

Have anyone read their best practices? It is this thick… There is a white paper online that is only a couple of pages. I suggest that you read it as it gives you pointers to what to look at.

The idea behind following best practices are that it makes life easier when handling updates and upgrades of your CRM system. The CRM platform could, after an update, change in ways that break an unsupported customization. But if you have followed best practices and have supported customizations they should continue to work after these updates.

Another reason to stick with supported customizations are that with a short time to market, release pace is quite quick. Your time to prepare is short, and it’s much better spent bringing the new features and functionality into your solution than fixing unsupported code so it doesn’t break your company’s or a customer’s deployment.

Microsoft also recommends that you consider the long-term maintenance requirements, and use the tools in CRM for building business logic when possible. They say that configurations are easier for others to analyze and understand without having to open up Visual Studio. These tools are a more integrated part of the CRM solution, which means that they’ll be checked for compatibility during solution import. And while it’s easy to write code that doesn’t follow Microsoft’s guidelines, it’s really hard to do that with a configuration. That is, writing unsupported code is easy, having unsupported features by using configuration is hard.

They also have the recommendation that you should use workflows instead of plug-ins, and business rules instead of JavaScript. They say that choosing configuration can potentially improve performance, require less maintenance, and decrease the number of bugs in your solution.

But, I think that there are a couple of drawbacks following these best practices. When using configuration, it is hard to have the kind of version controlled system that a lot of developers are used to. For instance, you can’t have several developers working with customizations at the same time in the same system. Branching of your solution is near impossible. With configurations, it is hard to do isolated testing. It is a pain having several different environments when working with configuration.


We always deliver a new CRM system, whether it is on-prem or online, using automated testing and continuous delivery. We do this through code. But we do it in a way so that we don’t violate best practices, because we usually maintain the systems that we’ve built. And we don’t want to spend time fixing our own unsupported customizations…

With that in place you are able to run automated unit tests and integration tests of your CRM solution. You also have to possibility to abstract away your CRM database and test everything locally with an in-memory database. That way you have easy control of your data and can use data driven testing.

We’ve found that using Typescript instead of JavaScript gives you all the benefits of a strongly typed language and it compiles to standard JavaScript. The JavaScript can then be injected into the solution at deployment. That enables you to test your JavaScript resources in isolation.

So Microsoft does some pretty cool things, but Microsoft – when you need to brush up your existing best practices come talk to us. We’ve got some ideas how to improve them to get better automation and continuous delivery…


So, to sum things up:

I’ve talked about that it is easy to go to the cloud because of the low entry-barrier.

I’ve talked about how it gives you flexibility. You can start small, fail fast, and learn continuously without a large capital investment. Which enables agility and shorter Time to market.

It lets your business focus on creating value instead of managing hardware.

It eases your adoption of continuous integration/deployment and devops.

It gives you control over cost

The cloud makes sure that you don’t outgrow your solution


And it is fun