Two job adverts caught our attention recently. One was for an “ERP Business Analyst” to “help implement a large scale ERP implementation.” The other was for a “Dynamics 365 CE/CRM Developer.” Neither is unusual. When an organisation starts a Dynamics 365 implementation, one of the first questions is who will do the work, and the usual answer is to start hiring.
Hiring is often right. It is rarely the whole answer. Below we set out the roles a Dynamics 365 project needs, which of them usually belong inside your organisation, which are better brought in, and the problems we see when the balance is wrong.
What those job adverts tell us
A request for an ERP business analyst on a “large scale” implementation usually means the project is already approved and someone has realised that nobody internal has time to document processes, run workshops and turn the business’s needs into requirements. That is a sensible thing to notice early.
The CE/CRM developer advert points to something else. The organisation expects to extend Dynamics 365 Customer Engagement (Sales, Customer Service, Field Service and the Dataverse platform underneath) with plug-ins, client-side scripts, Power Automate flows or custom components. Sometimes that work is necessary. Sometimes it is a sign that the system is being reshaped to match old habits instead of the business adjusting to standard functionality.
Both hires can work well. The risk is treating them as a substitute for implementation experience. A good analyst who has never been through a Dynamics 365 go-live, or a strong developer who has never had to support their customisations through Microsoft’s update cycle, will learn on your project and at your cost.
On one project, a 120-person UK engineering firm moving to Business Central hired a business analyst six months before we started. She knew the business well but had not been through an ERP go-live. We agreed early that she would run the process workshops and own the requirements log. Our functional consultant sat in on each session and pointed out where standard Business Central already covered the need. That cut the list of proposed extensions from around thirty to eight. She is now the system owner. She handles most change requests herself and calls us for the larger pieces of AL development.
The roles a Dynamics 365 implementation actually needs
Whether the product is Business Central, Finance and Supply Chain Management, or the Customer Engagement apps, the same roles come up on every project. Their size varies.
- Executive sponsor. Someone senior who can settle disputes between departments and protect the budget and timeline. This role cannot be outsourced.
- Project manager. Usually one on each side, yours and the partner’s, with clear agreement on who owns which plan.
- Process owners. The people in finance, operations, sales or service who decide how work will be done in the new system and sign off on it.
- Business analyst. Runs discovery, documents current and future processes, writes requirements and keeps track of decisions.
- Solution architect. Decides what is configuration, what is extension, what is integration, and what is left out. This is the role that most often decides whether the system can still be maintained three years later.
- Functional consultants. Configure the application modules and know the standard functionality well enough to push back on unnecessary customisation.
- Developers. Build extensions, integrations and reports. On Business Central that means AL extensions. On Customer Engagement it means plug-ins, JavaScript, PCF controls and Power Platform components. On Finance and Operations it means X++ and the data management framework.
- Data migration lead. Owns extraction, cleansing, mapping, trial loads and reconciliation.
- Testers. Ideally the actual users, supported by someone who can write test scripts and manage defects.
- Training and change lead. Makes sure people can use the system on day one and know where to go for help.
What to keep in-house and what to bring in
We suggest a simple test: if the knowledge needs to stay after go-live, own it internally. If it depends on having done the work many times before, bring it in.
Keep in-house:
- Sponsorship and decision-making. A partner can recommend, but your organisation has to decide.
- Process ownership. Nobody outside your business should define how your month-end close or your service escalation works.
- Data ownership and cleansing. A partner can build the migration tooling. Only your people know which customer records are duplicates and which stock codes are obsolete.
- A long-term system owner or administrator. Someone has to run the system after the project team leaves.
- Testing by real users. Acceptance cannot be delegated.
Usually better brought in:
- Solution architecture, especially for a first implementation.
- Functional configuration, where knowing the standard product saves the most time and money.
- Specialist development and integration, unless you have ongoing work to justify a permanent role.
- Migration tooling and approach.
- Go-live planning and cutover.
Hire internally if the ongoing work justifies it: business analysis and development. The BA hire in that first advert makes sense if the role continues after go-live as the bridge between the business and the system. A CE developer hire makes sense if you have a steady stream of change requests, integrations or Power Platform work ahead. If the role exists only for the project, a contractor or partner is usually cheaper and less risky.
Where implementations commonly go wrong
These patterns come up again and again, whatever the product or size of the project.
Customising before understanding the standard product. Teams write requirements based on how the old system worked, and developers build exactly that. The result is more code to maintain and test with every Microsoft update. A functional consultant who can say “the standard feature does 90% of this, can you live with the rest?” is worth a lot.
Leaving data migration until late. Migration is treated as a technical task for the final month. In practice it takes several trial loads, each one surfacing data quality problems that need business decisions. Start early.
Unclear ownership between the client and the partner. If nobody knows who signs off on a design decision, decisions stall, or they get made by whoever is in the room.
Testing that doesn’t involve real users. If the testers aren’t the people who will use the system, problems surface after go-live.
Splitting ERP and CRM without a plan for both. Many organisations run Finance and Operations or Business Central alongside the Customer Engagement apps. If the two are implemented separately without an agreed integration and data ownership model (who owns the customer record, where pricing lives, how orders flow), you end up rebuilding integrations later.
A 90-person distributor in the Midlands moving from Sage 200 to Business Central had planned data migration for the final month. When we ran a first trial load eight weeks out, it showed around 700 duplicate customer accounts and a few hundred stock items with no unit of measure. Nobody had set aside time to decide which records to keep. We moved go-live back by a month and set up a weekly trial load with a reconciliation report. The finance manager and the warehouse lead each spent an hour every Friday working through the exceptions. By the fourth load the figures matched, and go-live itself was quiet.
A practical checklist before you start hiring
Use this before you post the job advert or sign with a partner.
- Name the executive sponsor and confirm they have the authority to resolve disagreements between departments.
- List the processes in scope at a high level: order-to-cash, procure-to-pay, record-to-report, case management, field service and so on. Mark anything out of scope.
- Identify process owners for each area and confirm how much of their time is committed to the project.
- Decide which Dynamics 365 products you need (Business Central, Finance, Supply Chain Management, Sales, Customer Service, Field Service, Power Platform) and how they will connect.
- Write down your current systems and integrations, including the spreadsheets people quietly depend on.
- Assess your data: where it lives, who owns it and how much cleansing it needs.
- Map each role from the list above to a person: internal hire, existing staff, contractor or partner.
- For every internal hire, ask whether the role continues after go-live. If not, think about other options.
- Agree a principle on customisation, for example: standard first, configuration second, extension only with a written business case.
- Plan who owns the system after go-live: support, administration, Microsoft update testing and change requests.
- Set aside user time for testing and training in the plan, not as an afterthought.
- Agree how decisions are recorded and signed off between your team and any partner.
Talk to us
If you are planning a Dynamics 365 implementation, or you are already hiring for one and want a second opinion on how to structure the team, we are happy to talk it through. We work across Business Central, Dynamics 365 Customer Engagement and the Power Platform, and we can help you work out where a partner adds value and where your own people should lead.
We usually start with a two or three day discovery workshop. It ends with a written scope, a view of what should be standard, configured or extended, and a suggested split of roles between your team and ours. Some clients then ask us to deliver the implementation. Others already have an in-house analyst or developer and want us alongside them for architecture, functional guidance and design review.
Get in touch through vizorsol.com and tell us where your project stands.