How to convert an unmanaged solution into a managed solution in Dynamics 365?

“You see, but you do not observe.” — Arthur Conan Doyle, A Scandal in Bohemia

I had an unusual scenario where an environment was setup with an unmanaged solution and I wanted it to be a managed solution and I needed to convert it. All environments beyond Dev should be managed, so users cannot change customisations. Changes should be made in development and the other environments use the functionality but don’t change it. Stopping changes in environments stops them becoming out of sync, which can affect your testing in those different environments because you are not testing the same customisations.

Converting the solution

I imported the solution with the same publisher in a managed state; I was hoping this would just overwrite the unmanaged solution and customisations and turn them into managed. On import it threw an error and wouldn’t let me convert the unmanaged solution into a managed solution.

Why wouldn’t it let me overwrite it to managed?

I think it’s there to stop developers accidently converted their development environment into a managed environment. This would of a disaster for a development environment because you could no longer change your customisations.

If you did this, the first thing to do when you find yourself in a hole is stop digging. Microsoft backs up your environment hourly for up to 7 days in the past. If you need too you can restore to any hour in the last week. Before you get too excited, remember you would lose customisations and data. It’s very difficult to know what data has been updated and the effort to recreate it is manual, this makes the hourly backup a last option scenario.

Converting the customisations to managed

The internet offered me no help, so I got to thinking (some articles to help you think about your problems)

An unmanaged solution is a container for customisations, if you delete the unmanaged solution, it only deletes the solution. A managed solution is different, if you delete a managed solution, you delete all the data and all the customisations. 

The solutions act differently because unmanaged solutions update the default solution with unmanaged solutions. Managed solutions create another layer of customisations on top of the default solution.

Read more about solution layers

There is a solution layer button is useful to find out how many solutions and different customisations are overlapping on a particular component. This can help diagnose puzzling behaviour and when people have been updating an environment directly.


I deleted the unmanaged solution and then imported the managed solution and this time it worked and turned the unmanaged customisations to managed.

Hosk top 10 articles of the week - 6th April

S. N. Behrman meant when he said “At the end of every road you meet yourself.”

I have been interested in Systems thinking and Coronavirus

Article of the week

The Doctor Who Helped Defeat Smallpox Explains What’s Coming

Larry Brilliant is a amazing and this article is great

Chesterton’s Fence: A Lesson in Second Order Thinking 
This is so relevant for developers and consultants who are often faced with the prospect of removing or replacing customisations

A core component of making great decisions is understanding the rationale behind previous decisions. If we don’t understand how we got “here,” we run the risk of making things much worse.

Hosk Recent articles

Top 10 articles

  1. Design thinking, Design doing
  2. Leverage Points: Places to Intervene in a System
  3. The Rise and Fall of Object Oriented Programming
  4. The Supersoaker Principle
  5. Second order thinking
  6. How to not get bored with life
  7. Double loop learning
  8. The economics of cruise ships
  9. Systems thinking in action
  10. The fallacy of requirements


  • Video — Masterclass with Chris Voss negotiator



  • “It’s what you learn after you know it all that counts.” proverb
  • When the pressure is on you don’t rise to the occasion, you fall to your highest level of preparation — Chris Voss

Selected HoskWisdom

  • Don’t remove code until you understand what it does and why it was added #HoskWisdom
  • 50 percent of problems on IT projects are people, the other 80 percent are estimates and expectations #HoskWisdom
  • Small problems can turn into large problems if you ignore them #HoskWisdom
  • A good leader is a pricessless gift, a poor leader is a punishment #HoskWisdom
  • Sometimes the best thing to say, is nothing at all #HoskWisdom
  • Most Dynamics 365 developers are looking for an excuse to create a plugin #HoskWisdom
  • Don’t waste time making things perfect today, they will be replaced by something new tomorrow #HoskWisdom
  • No solution is right for every scenario #HoskWisdom
  • Between success and failure is trying, learning and improving #HoskWisdom

Follow the hastag #HoskWisdom or follow me on twitter BenHosk

Quote from current book(s)

The Rules of Contagion: Why Things Spread — and Why They Stop

The crucial change happens at the peak of the epidemic. At this point, there are so many immune people — and so few susceptible — that the epidemic cannot continue to grow. The epidemic will therefore turn over and start its decline. Adam Kucharski

The Hosk — last 5 good books

Don’t deny yourself a book, it could change your life #HoskWisdom

Last top 10 article

If you want more links, check out the link

Last top 10 article

Why IT projects estimates are wrong

Why we start IT projects as optimists and finish them as pessimists #HoskWisdom

No one starts a project thinking “this project will be late”. When we start project the requirements seem straightforward, the solution seem good and you have an eager team ready to go.

Then the project starts…………

Suddenly the assumptions are wrong, requirements are multiplying and SME’s have gone on holiday. IT projects are difficult, many of them fail, most developers have worked on at least one failed project but when we start a new project we think

This time it will be different

Hope is not a strategy

I’m not saying don’t have hope but be prepared for difficulties and don’t lose hope when things get tough (because they will). The solution you thought you were delivering will be a lot different from the project you end up delivering. This shouldn’t wear down you hope it should reinforce it because it means you have adapted to feedback and delivering what’s needed not what the high-level requirements hinted at.

High-level requirements are a guide to what the solution but without the details. High-level requirements create high level solutions, and they are always right with no gaps. They are a starter, a placeholder for everyone to learn more about and estimate what’s required both with the requirements and the solution.

The inside view of an IT project is your estimate, the outside view looks at the average length of similar projects. It’s difficult to take a statistical or average view of project lengths because every project is different, but we should use average project lengths to help review the project estimates and give it the smell test.

Estimates are likely to have been optimistic because they used high-level requirements, the more you dive in the details, the more requirements will appear. Everyone should be prepared for this, the real requirements are unknown at the start of the project, so it’s impossible to estimate them.

Estimates do not predict any problems such as

  • Technical problems
  • People leaving, starting
  • Virus pandemics which cause everyone to work from home!
  • Changes of priority/decisions
  • No SME’s

You can’t plan for unforeseen events, problems and people, but you can check for optimistic estimates by comparing it with similar projects. Compare the number of complications that occurred on similar-sized projects (team size, project length, scope)


Projects evolve and learn more about the detailed requirements, the team and the solution. It’s not the challenges which are important, it’s the projects response to them.

IT Projects are a team game and it’s not made up of separate teams (Customer, contractors, developers, different technical teams, etc). A project team is one whole team who all have to trust and work together to create one solution.

The team has to be flexible and respond to changes, mistakes and feedback to create whats best for the business.

The solution you end up with at the end of the project will be different to the solution you planned to create.


Projects will change from the initial scope. Everyone involved thinks their project will be special and with the talented people can do it quicker than other projects. 99 percent of the time they won’t, base rates guide us when are optimism tries to take over.

Use similar projects as a guide

  • how long did it take?
  • how many problems happened?
  • What extra requirements appeared?

Don’t forget estimates are not commitments.

IT projects are the fastest way to grow grey hairs” #HoskWisdom

Keep learning

Countering the Inside View and Making Better Decisions

picture from here

Dual-write is available to integrate Dynamics applications in near time

Dual-write brings the possibility of integration with configuration not customisation, woohooo

Dual-write was released this week after a year of people trying it and deciding it isn’t ready yet. I sometimes criticise Microsoft for releasing functionality early but the advantage is we get to try the functionality, help Microsoft test it and get a deeper understanding of what the functionality can do now and it’s potential.

Integrated Dynamics applications

The reason I’m skeptical about new functionality is because it rarely matches the marketing that precedes it. The marketing is exaggerated but the documentation is good. Microsoft has been telling everyone separate Dynamics applications are integrated for years. This left partners delivering projects in the position of explaining can but it will take a bunch of time to make them work together.

How we got here

The Dynamics applications and services have been drifting towards each other and over the last year at an increasing speed. Microsoft cleaning up the unsupported customisations and replace them with controls, allowed them to create CDS. I llove the fact they created CDS by using a plain Dynamics 365, it’s framework and infrastructure to create a plain database to build integrated customisations on.

CDS, connectors and Azure customisations (Power Automate, Logic Apps, Azure functions) to link services together to create powerful solutions.

CDS allows you to mix data from different Dynamics sources , so you can put data from Dynamics CE and Dynamics F&O together.

Microsoft moved from a strategy of developing multiple applications to creating services that can be used by all the Dynamics applications. CDS shares data and the connectors allow you to link Dynamics services/CDS to other services (Azure, Twitter, exchange).

Integrating data between Dynamics applications creates interesting questions 

  • Do you need to have the data in both systems? 
  • Which system is the master?

Dual-write capabilities?

Dual-write allows Dynamics F&O to be integrated to CDS in a near real time (almost instantly) and its bi-directional. It’s built on the common Data Service. Stick to the common data model and you will save yourself lots of work.

If you change an account In F&O it copies the data instantly to CDS and vice versa. The big win is it does this with no need to write any lines of code, it’s only configuration baby.

To get the facts on Dual-write, read the blog posts below

This picture nicely captures the capabilities of Dual-write from the second blog post above

Dual Writes benefits in Dynamics 365.

The interesting concepts from above are transforming, which you can see the need to do when mapping F&O and Dynamics.

Does it work?

Most Dynamics people I speak to want this functionality to work and the Dynamics products to integrate out of the box. I saw it tried on a project August last year and it was slow and could only copy to the default business unit, which made it unuseable.

Dual-write is the direction of travel for Microsoft Dynamics projects, so get used to it and get learning about it because this future of Dynamics projects. When you can see Microsoft is investing in a service (like Power Apps, Power Automate, Power Hosk :-)) it makes sense to move in that direction and swim with the tide rather than against it.

Dual-write combines with the improvements in the Common Data Service and you can see what entities are in phase 1

Data in Common Data Service — Phase 1

What should you use it?

These are the reasons Microsoft recommend Dual-write

  • Data from customers, products, operations, projects, and the Internet of Things (IoT) automatically flows to Common Data Service through dual-write. This connection is very useful for businesses that are interested in Microsoft Power Platform expansions.
  • The dual-write infrastructure follows the no-code/low-code principle. Minimal engineering effort is required to extend the standard table-to-table maps and to include custom maps.
  • Dual-write supports both online mode and offline mode. Microsoft is the only company that offers support for online and offline modes.

If you can use it, then you should because it’s configuration, which means it’s low maintenance and will allow you to deliver an integrated solution faster. It’s worth to try it first because it will save you time on the project. I don’t think there is a cost (apart from licences for F&O and CDS/Dynamics). This could and probably will change but lets worry about that later.


These are the questions I have at the moment

  1. What happens to records that can’t sync? What about error handling?

The answer to this was in this blog

Alerts are especially useful in case of unplanned maintenance, when one of the apps is unavailable and based on your defined thresholds, dual-write goes into a paused state wherein all new requests are queued (but not lost). After you fix the underlying issue and both applications are running smoothly, you can resume from the paused state and the updates are read back from the queue and written to the recovered application.

It sounds like there is a queue in the background, which you would expect because you don’t want to lose any messages.

2. What capacity can Dual-write deal with?

3. What are the limitations for Dual-write?

These questions will be answered as more people use it and learn about it’s limitations and capabilities.

Further reading

There are some useful Microsoft docs

To deliver a project on time, stick to out of the box (if you can)

There is never enough time to build the solution the customer thinks they want #HoskWisdom

Don’t ask a developer if a requirement needs code. Don’t ask users what enhancements they would like and don’t ask a barber if you need a haircut.

A developer told me he worked on a project that delivered on time and the customer loved it. I have worked on many projects and few delivered on time (obviously not my fault :-)), so I was curious to learn more.

On this project they kept telling the users they couldn’t have what they asked for and they were just getting out of the box. The team mantra was.

“You get whatever out of the box can do and no more”

The outcome of this stance (supported by the leadership of the customer).

  • User stories were straightforward and didn’t need lots of rewriting.
  • Development was mostly configuration with some no code customisations.
  • Testing went through with few bugs.
  • The project delivered on time and on budget.

The user got the system and loved it. After using it for a month, they came back with a few improvements and enhancements. This project was a Field Service project, but I saw a portal project delivered in 3 months from start to go live which used a similar approach.

Imagine the time saved by sticking to and trying the out of the box solution before suggesting enhancements. It seems obvious, but the common problem on projects is scope growing, expanding the complexity of the solution and testing. 

This compounds the usually optimistic estimates of a project and reduces the time you have to test and fix bugs. Problems found at the later stage of a project are deadly because there is no time to reduce scope and then go live gets pushed back.

The order of customisations

The general order of creating customisations is

  1. Out of the box.
  2. No code customisation (workflow, Power Automate)
  3. More powerful no code — (Logic app, PowerApps)
  4. Code (Plugins, Azure Function)

The reason for starting with out of the box because of the cost of maintenance. Every customisation you create has to be maintained, tested, debugged, deployed, upgraded and understood from that point of creation. Code allows you to create more complex customisations but has a higher maintenance cost and fewer resources can do that.

The benefit of using out of the box is Microsoft takes the burden of testing, upgrading and maintaining.

Charlie Munger often says that “to a man with a hammer, everything looks like a nail.”

To someone who can write code, all problems can look like a plugin, many Dynamics developers enjoy writing code more than creating no code solutions. To reduce the complexity and maintenance of your solution, stick as close to out of the box as you can.

Users and wishlists

I have seen examples of users coming up with growing list of requirements that would be nice to have and might make their jobs easier. It’s easy to capture a requirement but then it must be created, tested and moved through all the environments until you get to production, where its then supported.

Every requirement comes at a cost and the most significant is time.

The more requirements you add, the more time to deliver and the more complex the solution becomes. The more customisations which are linked the greater the complexity in understanding the solution.

Find what customisations they need, build those and let the users test the system. This delivers functionality into production and not wasting time on functionality not required. After using the system the users can highlight the pain points and areas where the new system would benefit from enhancements.

You create customisations where you need them, not where the users think they need them. For every requirement, question if it’s really needed? Show the out of the box solution and get users to test it. It’s difficult to push back on requirements but every requirement you add the more likely the project will not be on time.


  • Question every requirement, take only what’s needed.
  • Show out of the box solutions and persuade them to try them.
  • Code should the last choice.
  • Persuade users to test the solution before enhancing it.

The fewer customisations and code you create, the quicker you will get through testing and deliver to production. Get feedback from users to find out where they really need to enhance the system through them using it.

Most users don’t know what they want, until you show them what they asked for and they know it’s not that. So ask them to try out of the box and then know what they want.

Everyone on a project wants it to be successful and on time, be focused and disciplined.

Articles and quotes to make you think - 19th March

Here are the best articles and quotes I read last week, which got me thinking.


Gather together the things that change for the same reasons. Separate those things that change for different reasons Robert C Martin

“Unless people can express themselves well in ordinary English, they don’t know what they are talking about.” Russell L. Ackoff

Latest Hosk articles

10 Interesting articles last week

  1. The Powerful Differences Between Good and Great Programmers
  2. Single Responsibility Principle (SPR) explained by Uncle Bob
  3. Embracing complexity
  4. Sometimes being slightly better than the competition is enough to win big — James Clear
  5. Great advice in investing and mental models and perspectives at looking at the world
  6. How to Write Usefully — Paul Graham
  7. Using Models to Stay Calm in Charged Situations
  8. How does system thinking help solve problems
  9. How To Be Successful
  10. The story behind ‘flatten the curve,’ the defining chart of the coronavirus


  • The truth of code can be confused by the lies in comments HoskWisdom
  • Code should be self documenting, the purpose of classes, methods and variables should be obvious that you can understand it in six months time #HoskWisdom
  • People don’t care if the chicken came before the egg, but it doesn’t stop them asking #HoskWisdom
  • Stop dreaming of the quiet project because it’s the one you’ll never know — Paul Weller
  • Criticism drains motivation and confidence, encouragement boosts it #HoskWisdom
  • Design should emerge from requirements #HoskWisdom
  • A developer thinks they are the master of code, while in fact code remains the master of the developer #HoskWisdom
  • When you create two versions of the truth, the result is a maintenance overhead that drifts apart #HoskWisdom

Classic Hosk article

Questions on Microsoft Dynamics Dynamics 365 solutions and environments 

Quote a book I’m reading

The Fifth Discipline: The Art and Practice of the Learning Organization

The key to success isn’t just thinking about what we are doing but doing something about what we are thinking. Peter Senge

Code should be the one version of the truth, don’t add comments


“Code never lies; comments sometimes do.” — Ron Jeffries

Code should be self documenting, the purpose of classes, methods and variables should be obvious that you can understand it in six months time.

The reason I don’t like comments in code is because you have to maintain the code and the comments. I have seen examples where developers have changed the code but not the comment. When code and comments are out of sync, readers aren’t sure if the code or the comment is wrong. In most cases it’s possible to name the variables and methods for it to be clear what it’s doing, making comments redundant.

It’s easy to underestimate the effort needed to create obvious naming, first attempts are usually not as clear as they can be, you shouldn’t release your first draft. Make the naming clear, so someone who hasn’t worked on the code can read it and understand it.

You should add descriptions to classes and public methods because this can generate documentation. You should document code when you have written unusual code that is doing something odd that people would be tempted to refactor it.

“Don’t repeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” — Andy Hunt and Dave Thomas


Adding comments break the DRY principle because it creates two versions of the truth, When you create two versions of the truth, the result is a maintenance overhead that drifts apart.

Naming gone wrong

The naming of classes, method and variables should make its purpose obvious, removing the need for comments.

Clear naming of code relies on applying the single responsibility principle (SRP) to your code. SRP means each class, method and variables should have one responsibility. Robert C. Martin encapsulate this well by saying SRP should mean a class should one reason to change.

Reading more about SRP

Common signs you have broken SRP and the method/class is doing too much is when it’s hard to name because it’s doing more than one thing. Names like.

  • UpdateAndSave
  • ContactNumberorEmail
  • CreateReportAndUpdate

Methods which are hard to name are because the class or method are doing multiple things. This code has multiple reasons to change, hard to test and difficult to understand. Bad code is hard to name.

The truth of code can be confused by the lies in comments — HoskWisdom


Developers think adding comments helps understand the code. My experiences is comments rarely add anything to the code, or they have written comments instead of applying SRP and naming properly.

Comments are like commented out code, it adds confusion and increases the maintenance costs. Every line written has a maintenance cost and the potential to create a bug, the less code and comments the better.

Comments intuitively seem useful, but they are not what many developers think they are. The same qualities that give comments strength are it greatest source of weakness. Comments create two versions of the truth, a maintenance overhead and encourages developers to put less effort into naming. Most developers would be more productive to spend the time on refactoring the code and improving naming.

Most comments in code are written by junior developers thinking they are helping or by bad developers trying to explain their poorly written code.