Insights

Microsoft Dynamics 365 provides a powerful CRM platform for businesses. However, its implementation can be challenging.

As experienced Microsoft Dynamics 365 CRM partners, we understand what factors contribute to successful deployment.

This guide presents best practices, highlights common pitfalls, and offers key insights for a smooth Dynamics 365 implementation.

Disclaimer: The high-level information in this article is for informational purposes only. It reflects the authors’ opinions, and we are not responsible for any actions taken based on this information. We always recommend consulting a certified Microsoft Dynamics 365 partner before making any decisions, as Dynamics 365 implementations are complex and require expertise to plan and carry out.

Planning and strategy

Implementing Microsoft Dynamics 365 successfully requires thorough planning and a well-defined strategy.
Working with an experienced Dynamics 365 partner is essential, as their expertise can greatly improve your project’s outcome.

Planning will usually cover considerations such as:

• Scope
• Budget
• Goals
• Timelines

In addition to these areas, there are a few important points that we always highlight during the initial stages of a project:

Transitioning from an existing system

When planning your Dynamics 365 requirements, we’ll ask you to consider both the positives and negatives of your current system if you have one. Often, organisations focus solely on what their old system lacks, neglecting its useful features that should be carried over.

Defining the role of Dynamics 365

We recommend clearly defining the purpose of Dynamics 365 within your organisation from the outset and keeping this in mind throughout the implementation and ongoing use of the system in future. We find organisations often lose sight of this with time.

This focus will help prevent the system from becoming cluttered with unnecessary data. Remember, Dynamics 365 isn’t a data warehouse. Instead, ensure that only data essential for your CRM functions is included.

For instance, due to the ease of extending Dynamics, we often find that established systems have lost their identity where more tables and data have been added, altering the system from its original purpose.

Keeping this in mind from the beginning can help maintain focus and contribute to success. For example, if Dynamics 365 is used as a CRM system, it should primarily require data that aids in serving customers effectively.

Consider your data

Further to this, it’s important to differentiate between data that needs to be in the system and data that just needs to be visible. It’s often possible to use virtual entities and Microsoft Power BI reports to display relevant information from other systems.

For example, customer order histories could be viewed within Dynamics 365 without being stored there if they originate from your finance system etc.

If something isn’t going to be triggering any workflows or business logic etc. in Dynamics 365, it’s often beneficial just to surface the data, which can save on storage and keep the system cleaner.

Summary

Proper planning and the guidance of experienced professionals can lead to a more efficient system, potential cost savings, and a better overall user experience. So, work with your partner to create a clear plan and set yourself up for success.

Licensing considerations

Navigating the complexities of licensing and costs for Microsoft Dynamics 365 can be challenging. Again, working with a partner will help significantly here.

Dynamics 365 licences

Purchasing Dynamics 365 licences is often complex. It depends on user activities, app access, and specific needs.

Instead of defaulting to the expensive Sales Enterprise licences, we often recommend starting with minimal licences until your system design and development has taken place, and the requirements have become clearer.

We also encourage customers to carefully evaluate premium entities like ‘Cases’, ‘Omni Channel’, or ‘Copilot’ etc. to determine if they are necessary for the core requirements and budget.

Microsoft Azure costs

Azure resources for integrations can vary widely in cost. Microsoft Power Automate isn’t usually suitable for full integrations, so we typically use Azure Functions apps for integrations. Since Azure pricing is consumption-based, with different tiers available, until you know what’s going to get run through those functions, you won’t know how much it’s going to cost you. The reality is no one, including your partner, is going to know.

Therefore, we typically recommend ring-fencing a budget for Azure costs and working with your partner to estimate as realistically as possible, while being prepared for the true cost to be higher or lower.

Summary

In summary, ongoing costs for Dynamics 365 licences and Azure resources are complex and can change post-implementation. Regular reviews of licence usage and exploring different models will help optimise costs and accepting some budget flexibility is crucial for long-term success.

Deployment considerations for Dynamics 365

Deploying Microsoft Dynamics 365 requires careful planning. Working with a partner can help you set up your environments correctly, avoiding costly errors which can’t be reverted.

Choosing your environments

We usually recommend having four environments:

• Development
• QA
• UAT
• Production

Storage

Each empty Dynamics environment takes up significant space—almost 4GB—so plan your storage needs carefully. The free 3GB storage included with some licences can get used up almost immediately, often surprising customers.

Deployment options

You’ll need to decide on factors such as geographical regions and base currency. Your partner can guide you to avoid making incorrect selections that can’t be changed later.

Dataverse vs. Dynamics environments

It’s crucial to decide whether to use a Dataverse or Dynamics environment. Your partner should guide you through the differences and help you determine your needs.

The two are quite different and if you’re deploying a Dataverse environment, you can’t later move to a Dynamics environment. If there’s any chance you might want any Dynamics 365 apps like Dynamics 365 Sales, Customer Journeys, Field Service, or Customer Service etc. in the future, we’d always recommend a Dynamics environment.

Dynamics environments allow for future expansion without requiring Dynamics licences at the start. For example, we often deploy a Dynamics environment but build a model-driven app that uses per app licences. This just means some of the Dynamics tables can’t be used at first, but you can always move to Dynamics licences later to expand the system and take advantage of extra functionality if you choose to do so.

However, if you definitely don’t need Dynamics capabilities and have a small specific use case, a Dataverse environment may be more suitable and efficient in terms of storage.

Summary

There are many considerations when deploying Dynamics 365 environments. Work with a knowledgeable partner who can guide you through the options to ensure your system is set up to support your long-term goals and future-proof your operations.

Development practices and system governance

Implementing effective development practices and system governance from the outset is crucial for the success of your Microsoft Dynamics 365 system. A knowledgeable partner can help you set these up correctly, even if you plan to manage development in-house later.

Pipeline Management

Using multiple environments for Development, UAT, and Production is key. Ideally, we recommend many of our customers also have a QA environment, depending on specific needs.

All changes should be made in the development environment and then transported upstream using pipeline management. Direct changes should never be made straight into the Production environment, as this carries large risks and often leads to costly problems with discrepancies between environments.

For Power Platform environments, Microsoft provides pipelines to streamline deployment, which can even integrate with GitHub and Azure Dev Ops for committing the code. In Dynamics environments, we use Azure DevOps to manage pipelines and changes.

In a more advanced development situation, organisations might typically implement changes in the system, then document these changes within DevOps. The process would then involve creating a branch for the modifications, for review by another team member. Upon approval, the changes would be merged into the ‘master branch’ and subsequently deployed.

This diligence helps mitigate against unforeseen issues in production and ensures that all changes are verified and approved.

Good governance and “failing early”

Adopting a “fail early” approach during development is vital. Quick identification of bugs and fixes by developers can save significant time and resources. Early checks prevent issues from reaching UAT, QA or, worse, Production, where they can cause costly problems and potentially impact business operations once the system is live.

Establishing clear guidelines for coding standards, version control, and documentation is imperative. Regular code reviews and audits maintain code quality and compliance with best practices.

Summary

Good development practices and governance are key to the success of your Dynamics 365 system. Work with a partner to implement and manage best practices, ensuring your system remains robust in the short and longer-term. Even without a partner’s involvement post go-live, maintaining high governance standards and processes is essential to prevent unintended consequences.

Integrations

Integrations are a key part of Microsoft Dynamics 365 implementations.

Defining integration

The term ‘integration’ often causes confusion with customers. For example, some customers believe a button that opens a new window to another system as an integration, despite no actual integration. Or simply surfacing data from another system within Dynamics 365.

True integration, however, might involve the exchange of data between systems, where updates in one system reflect in the other etc.

More moving parts, more risk

Full integrations require careful planning. For example, in the scenario of a two-way integration, you’d need to determine which system is primary and which is subordinate etc.

When data is moving between systems, you’re also introducing risk. You’ll need to consider risks of scenarios such as data failing to move as intended, or if one system could inadvertently overload the other if one system wasn’t scalable enough etc.

Cost vs benefits

It’s vital to evaluate the necessity of integrations versus their costs. Custom integrations can be expensive and require ongoing maintenance.

There will be the upfront cost of development and testing, as well as bug fixes which are inevitable with custom integrations.

However, there are also ongoing costs to consider. Microsoft recommends developing in .NET Core, which necessitates periodic upgrades between versions to ensure the integration remains current with supported features and security. Although your partner may be responsible for the technical aspects of this, you’ll be responsible for paying for the time and costs involved.

Native integrations and connectors

Dynamics 365 offers native integrations with Microsoft apps like Teams, OneDrive, SharePoint, Outlook, and Excel. Microsoft Power Automate provides connectors for major software products, suited for lightweight automation, but not business critical integrations. Third-party integrations are also available, varying in complexity from click-and-install to those needing development time.

Summary

Custom integrations can be important for certain Dynamics 365 implementations to fully utilise the system’s capabilities. However, not every system needs custom integrations. It is essential to evaluate the business benefits and costs, and work with your Dynamics 365 partner to determine the most suitable integration strategy for your requirements.

Data and migration

Data migration is a crucial part of a successful Dynamics 365 implementation. Proper planning is key.

Cleaning your data

You’ll need to ensure your data is clean before the ETL (Extract, Transform, Load) migration process can begin. This involves organising information properly and ensuring it has consistent formatting and correct field usage amongst other things.

Professional data cleansing services exist if tidying up the data isn’t something you have capacity for internally.

Remember, migrating poor-quality data to a new system won’t improve it; a new system only emphasises the need for clean data, so be prepared to dedicate time or resources to this.

Extraction

Before data extraction takes place, it’s important to clearly define the scope and purpose of the data you want to transfer. We often recommend customers consider archiving or utilising services such as Long Term Retention for some data, instead of migrating everything.

Transformation

Work closely with your Dynamics 365 partner to determine where your information will go. This process is more complex than creating a simple mapping document, as records from the old system might split into multiple records in the new system. Collaboration is essential during data transformation.

Loading

The loading phase, usually handled by your partner, involves entering the data into your new system. This is when your system ‘comes alive,’ showcasing your business data in the new environment for the first time.

Summary

Data migration is a critical aspect of Dynamics 365 implementation. Effort will be needed to clean your data before migration, as poor-quality data will typically lead to the new system underperforming. A new system will not fix bad data, so it’s important that organisations don’t use bad data as a reason for moving systems.

User Acceptance Testing (UAT)

UAT is a vital and often challenging aspect of any Dynamics 365 implementation. Understanding that UAT is an ongoing process from the project’s beginning until go-live is crucial. Your users will need to balance their day jobs with UAT tasks, so it’s important to plan for this.

Start UAT early

We recommend breaking UAT into manageable chunks throughout the development phases, rather than waiting for the entire system to be built. This approach ensures users are not overwhelmed with testing all at once.

Our approach, as a partner, is that every time we do a release, which is typically every fortnight or monthly, we’ll do a playback with some training and request that the customer does a small chunk of UAT each time.

Balancing functionality and data during testing

One of the main challenges of UAT is asking users to test an empty system’s functionality. Users understandably often feel they need real business data in the system to do the testing, but this isn’t always possible earlier on in development.

Users may need to create records or use temporary data to ensure the system works as intended before the actual data migration.

Allocate time for UAT

Your users must dedicate time for UAT alongside their regular duties. UAT is more than just finding errors; it’s about familiarising with the new system, understanding its capabilities, and identifying any functionality gaps that weren’t identified or communicated earlier in the project.

Systematic approach

Every Dynamics 365 partner knows that all customers will miss some gaps in functionality during the earlier ‘requirements gathering’ phase of a project, which is normal.

Therefore, we always encourage users to think systematically about their daily, weekly, monthly, and yearly tasks. This will help ensure that the new system supports all necessary functions, even those the old system handled well.

Summary

UAT is critical for the success of your new system. Begin discussing your data and UAT requirements from the start of the project. Write your test scripts (e.g. “I can take a phone call”, “I can log a case”, “I can respond to a customer email” etc.) and allocate ample time for your users to engage in thorough testing, as time is usually the biggest problem for customers during UAT.

Go-live, system management, and ongoing maintenance

Preparing for Go-live

When your system is ready to go live, manage expectations early. Transitioning to a new system can feel overwhelming for some users. Adjusting to it takes time, and setting realistic expectations is key.

Post go-live adjustments

Excitement typically surrounds the culmination of months of hard work in the go-live phase. However, the work doesn’t end there. Within a week or two, users may find minor tweaks needed to improve system usability. It’s essential to budget for these immediate changes, as certain features might work differently in practice than anticipated during workshops and training.

Training budget

Allocate budget for ongoing training. Users can’t master an entirely new system and business processes in just one or two training sessions, especially if those sessions occurred well before the go-live date. Investing in additional training sessions or having an on-site ‘drop-in centre’ where users can ask questions can prove invaluable.

We typically recommend considering recurring training sessions within the first six months to a year. In the beginning, everyone is learning the system from scratch, so having a knowledgeable partner to guide users is crucial. Over time, users will become proficient and can then train new team members.

Ongoing management and maintenance

Once live, continuous management and maintenance are vital. Engage your Dynamics 365 partner for any system changes, no matter how small, even if you plan to make system changes in-house. A good partner can sense-check your changes and highlight potential risks.

Remember, “just because you can, doesn’t mean you should.” Dynamics fields may seem simple to modify, but without expertise, you might not foresee the ripple effects such changes could have elsewhere.

Summary

Managing expectations around go-live, planning for ongoing training, and preparing for both short-term and long-term system changes are critical. Always engage a Dynamics 365 partner for modifications to maintain system stability and efficiency. We recommend periodic reviews of system performance, enabling adjustments to be made to optimise efficiency over time.