Paris, 3,400 people, and a few unanswered questions
Almost 3,400 people joined us for Directions EMEA 2026 in Paris, roughly 10% more than last year. As one of the founders and organizers of Directions, I am obviously delighted with that result, although I have to admit that I am not entirely sure what brought all those additional people to the conference. Was it the agenda? The enormous interest in AI? The fact that so much is happening in the Business Central ecosystem right now? Or did we simply benefit from the fact that Paris is a rather attractive place to spend a few days in October? Probably a bit of everything. And I wouldn't underestimate the last point.
Being involved in organizing Directions gives me a slightly different perspective on the event. Of course, I follow the announcements, attend sessions when I can, and enjoy meeting people from across the ecosystem. But I also spend quite a lot of time thinking about where our industry is heading, what that means for the companies attending our conferences, and ultimately what Directions itself might look like in five years. This year, those questions were particularly interesting because I have rarely experienced a period in which so many things that we considered perfectly normal just two or three years ago suddenly seem open for discussion.
Apparently, everything now comes with AI
It will surprise absolutely nobody that AI dominated Directions EMEA 2026. There were AI announcements, AI demonstrations, AI development tools, AI agents, AI-powered add-ons, and probably a few products that discovered their AI capabilities shortly before the exhibition opened. I don't think I have ever seen so many solutions promising to change the way we work. Some of them were genuinely impressive, while others made me wonder how many of these products will still exist in twelve months. But more about that later.
Microsoft certainly contributed to the discussion with several announcements and demonstrations around Business Central. One of the developments I find particularly interesting is the new Copilot experience, which is becoming much more closely integrated into Business Central. With the capabilities presented around version 29, users can increasingly interact with business information using natural language, and Microsoft is also working on allowing Copilot to perform actions and modify information rather than simply answering questions. The various agents are another important development. Microsoft has been expanding the capabilities of agents such as the Sales Order Agent, Payables Agent, and Expense Agent, moving towards a situation in which routine business activities can be handled with much less manual interaction. There were also developments around quality management, subcontracting, electronic documents, EDI, analytics, and the overall Business Central platform.
However, the announcements that interest me most are those related to how we actually build and implement Business Central solutions. AI-assisted development, implementation agents, automated testing, and the continuing improvements to the development environment are changing the economics of software production. We are already seeing development activities that previously took days being completed within hours, and sometimes considerably faster.
I don't want to pretend that every complex customer requirement can suddenly be delivered in five minutes. We still need proper architecture, testing, security, and people who understand what they are doing. But I think we have reached a point where arguing about whether AI will significantly reduce development effort is no longer particularly useful. The more interesting question is what we are going to do with that development.
We may have to reinvent ourselves. Again.
I started my first company in 1998, and over the years I have heard quite a few predictions about how our industry would change and why partners needed to reinvent themselves. Some of those predictions turned out to be correct. Others were forgotten almost as quickly as they appeared. This time, however, I believe we are facing a change that will affect the fundamental business model of many Microsoft partners.
For decades, a considerable part of our business has consisted of analyzing customer requirements, identifying gaps, designing solutions, developing functionality, testing it, and eventually delivering the finished system. We have become quite good at this, and we have built our organizations and pricing models around the effort required.
Now imagine that the actual development work becomes five or ten times faster. Perhaps even more for certain types of requirements. I am not claiming that every development task can already be accelerated by those factors, but I think the direction is fairly obvious. A customer who previously paid for 100 hours of development will eventually notice if the same work can be completed in 10 hours. And I don't think telling the customer that our hourly rate has therefore increased by a factor of ten will be a particularly successful sales strategy.
This creates a challenge for partners, especially those whose business models depend heavily on selling development capacity. We need to find other areas in which our experience and expertise create value for customers. I actually believe there are plenty of opportunities, but they are not necessarily in the same places where we have been making our money for the past twenty years.
We need to change the way we run projects
One consequence of faster development is something I have been thinking about for quite some time, and it was also one of the main topics of my governance session in Paris. The traditional sequence of an ERP implementation no longer makes as much sense as it used to.
In the past, we could conduct a Gap-Fit analysis, identify the most important requirements, and start developing. Did we have every decision from the customer? Usually not. Were all processes properly defined? Sometimes. Was the master data in good condition? Well, anyone who has worked on ERP implementations knows the answer to that question.
Nevertheless, we could start developing because development itself took considerable time. While the developers were busy, the consultants could continue discussing requirements with the customer, collecting decisions, and clarifying how individual processes should work. It wasn't necessarily an ideal approach, but in many projects it worked reasonably well.
Now imagine that a development phase which previously took four months can be completed in four weeks. Suddenly, the customer no longer has three additional months to decide how the purchasing process should work. And this is where I see a significant problem.
We are accelerating the part of the project that the partner controls, while the part that depends on the customer is not necessarily getting any faster.
Customers still need to discuss their processes internally. Different departments still have different opinions. Management still needs to make decisions. Employees still need time to review and test solutions. In some cases, I would even argue that the customer will become the main bottleneck in the project.
That means we need to move considerably more work into the period before development begins. We need to help customers define their processes, clarify responsibilities, improve data quality , and establish a clear understanding of what they actually want to achieve with the implementation. The strategy behind the project becomes more important. Is the customer trying to reduce costs, standardize processes, improve transparency, or support growth? Those objectives need to be understood before we start producing functionality.
We also need much better Governance. Who is allowed to make decisions? Who owns a process? How do we handle conflicting requirements? And who decides whether a proposed customization is actually a good idea?
I have seen projects in which the partner could have delivered the requested functionality several times over while the customer was still discussing what they wanted. With AI accelerating development, situations like that will become increasingly difficult to manage. For me, this is one of the most important changes in our business.
We will need to spend more time helping customers prepare for implementation and less time actually producing the software. And I suspect that some customers will find that rather surprising when we explain it to them.
Will projects become smaller? I'm not so sure.
I have heard quite a few people suggesting that AI will make Business Central implementation projects dramatically smaller. That sounds logical. If development becomes faster, the overall project should require less effort. I agree with part of that argument, but I think we are overlooking something.
Until now, customization has always come at a price. If a customer wanted something very specific, we had to estimate the development effort, explain the additional testing, and discuss the implications for future upgrades and maintenance. Often, the cost was high enough for the customer to reconsider whether the standard functionality might be sufficient after all. And to be fair, that wasn't necessarily a bad thing.
But what happens if the cost of developing individual functionality decreases dramatically? What happens if a customer can get exactly the process they want without spending a fortune on development? I believe many customers will start asking for significantly more customization than they would have considered in the past. And if we can also maintain those customizations with considerably less effort, one of the strongest arguments against individual solutions becomes much less convincing.
This could lead to an interesting development. I can easily imagine a Business Central implementation with 20 users becoming just as complex in terms of individual processes, functionality, and integrations as a solution for a much larger enterprise. Not because the company suddenly needs enterprise-level infrastructure or organizational structures, but because the technical and financial barriers to individual functionality have become much lower. A small company may have very specific requirements, and for the first time it may actually be economical to implement almost all of them.
Whether that is always a good idea is another question. But I am quite convinced that we will see this happening. So yes, projects may become smaller in terms of implementation effort, but I don't necessarily expect the solutions themselves to become simpler. Quite the opposite, in fact.
In some ways, we are going back to 1998
There is something about all this that reminds me of how I started working with customers almost thirty years ago. In 1998, I sometimes sat directly next to the employee who was going to use the software. The employee explained what they wanted, and I developed it. Quite often, the person practically dictated what the software should do, and I implemented it exactly that way. There wasn't much discussion about standard processes or whether the requirement would still make sense in five years. The customer wanted something, and we built it.
Looking at the possibilities AI gives us today, I sometimes feel that we are returning to that approach. A customer describes a requirement, and the functionality can be produced almost immediately. However, there is one very important difference.
Back in 1998, every individual customization potentially created a maintenance problem. The more we developed, the more difficult upgrades became. Dependencies accumulated, documentation was often incomplete, and after a few years we sometimes ended up with systems that nobody really wanted to touch.
Today, we have tools that can help us understand, document, test, refactor, and upgrade software much more efficiently. I believe AI will make it possible to maintain even highly customized Business Central environments with substantially less effort than we needed in the past. I am not suggesting that we can ignore architecture or produce badly designed code without consequences. We can still create a terrible solution, and AI may even help us do that much faster.
But the long-term maintenance costs of customization could change dramatically. And if that happens, we may have to reconsider some of the principles we have been teaching our customers for decades.
Could this be the last ERP implementation for many customers?
This is a thought that has been developing in my mind over the past year or two, and the more I think about it, the more interesting I find it. What if the Business Central implementation a customer starts today turns out to be the last major ERP implementation that company ever needs?
For many years, replacing an ERP system every ten or fifteen years was quite normal. The old solution became outdated, maintenance was difficult, too many customizations had accumulated, or the system could no longer support the company's changing requirements. Eventually, management decided that it was time to start again. A new ERP system, a new implementation partner, a new migration project, and several years later everybody was hopefully happy again.
But what if we can continuously adapt an existing Business Central solution to new requirements? What if we can maintain customizations through future releases without the enormous effort that upgrades used to require? And what if AI allows us to modernize functionality, improve processes, and integrate new technologies without replacing the underlying ERP platform? In that case, many of the traditional reasons for starting a completely new ERP implementation may disappear.
Of course, I don't believe companies will never replace their ERP systems again. Platforms change, businesses change, and sometimes starting over will still be the right decision. But I can imagine the lifecycle of an ERP solution becoming considerably longer than it is today. Instead of replacing the system every decade, customers may continuously develop and improve what they already have.
That would be a major change for the partner ecosystem. We might see fewer traditional implementation projects and much more continuous work around process improvement, automation, data management, and business transformation. It is an interesting possibility, particularly for an industry that has been making a very good living from ERP replacement projects for the past few decades.
Some add-ons may have a difficult future
Another area where I expect significant changes is the ISV market. The Business Central ecosystem contains an enormous number of add-ons, ranging from highly sophisticated industry solutions to relatively small extensions that solve a particular functional problem. I believe many of the smaller ones will come under pressure.
If an add-on provides functionality that can be developed specifically for a customer within a few hours, the economic argument for purchasing a separate product becomes less obvious. Why pay recurring license fees for something that can be created relatively easily and maintained with the assistance of AI?
Of course, there are many exceptions. Industry solutions containing years of business knowledge, regulatory functionality, external services, complex integrations, or proprietary data will continue to have considerable value. And even a relatively small add-on can be worth buying if it is reliable, supported, and saves the customer from having to maintain another piece of software.
But I do believe that simply offering a few additional fields, screens, or relatively straightforward functions will become a much more difficult business model. We may see a significant consolidation in parts of the ISV market. And I suspect some products that look promising today will have disappeared before we meet again at Directions in a few years.
What will the partner ecosystem look like in five years?
This is where my perspective as a Directions organizer comes into play. Our conference depends on a strong, active, and successful Microsoft partner ecosystem. So naturally, I keep asking myself what that ecosystem will look like in the future.
Will the large Business Central partners become smaller because they need fewer developers? Will they retrain their employees to focus more on business processes, data, governance, and AI? Will we see many new, smaller companies entering the market because a handful of experienced people can suddenly deliver projects that previously required much larger teams? Or will customers start implementing and maintaining significant parts of their solutions themselves?
I don't know. And I don't think anybody else really knows either. My suspicion is that larger partners will have to reconsider how they use their employees. Some traditional roles will change considerably, and organizations that have built their business around large development and consulting teams may need to adapt.
At the same time, smaller companies could have an advantage because they can react much faster. It is considerably easier to change the direction of a company with ten employees than one with five hundred. I wouldn't be surprised if we saw a wave of new Business Central partners emerging over the next few years, perhaps with very small teams and an impressive amount of AI-supported delivery capacity.
But the opposite could also happen. If customers become more independent, perhaps there will simply be less work for traditional implementation partners. Maybe the number of partners will increase while their average size decreases. Maybe the larger partners will become even more dominant because they have the resources to invest in new technologies and services. There are several plausible scenarios, and at the moment I don't see enough evidence to confidently predict which one will prevail.
For us at Directions, this is a fascinating question. Will we have more partner companies attending our conferences in five years? Will they send fewer employees? Will the audience consist of different professional roles? Will traditional development sessions become less important while business transformation, governance, and AI orchestration become central topics? We will have to find out. I suspect the next few years will be anything but boring.
I remember the year 2000 rather well
One advantage of having been in this industry for almost thirty years is that I have already experienced a few technology revolutions. And some rather spectacular market corrections. Around the year 2000, during the dotcom boom, I remember companies appearing almost overnight with fantastic ideas, impressive presentations, and sometimes very little actual business behind them. Everybody needed an internet strategy, investors were throwing money at anything connected to the internet, and valuations occasionally seemed to have lost any relationship with reality.
Some of those companies became enormous success stories. Others disappeared six or twelve months after being celebrated as the next big thing.
Looking at the AI market today, I see certain similarities. We have an extraordinary number of new companies, products, and business models. Some will become very successful. Others will probably be replaced by something better before they have even established themselves. And some may simply discover that the functionality they spent a year developing has become a standard feature of a Microsoft product. We have already experienced something similar ourselves, and I suspect we won't be the last.
However, I want to make one thing very clear. I believe the AI revolution is considerably bigger than what we experienced around the year 2000. The internet fundamentally changed how we communicate, access information, and conduct business. AI is changing how we actually perform intellectual work.
Software development is only one example. Consulting, accounting, engineering, legal services, customer support, and many other professions will be affected. The potential impact is much broader than what we experienced with the internet.
What reminds me of the dotcom era is not the technology itself but the uncertainty surrounding the market. We know that something fundamental is happening. We don't yet know who the winners will be, which business models will survive, or how quickly the changes will take place. And I think we should be a little careful about believing every prediction we hear. Including mine.
Customers will become much more independent
Despite all these uncertainties, there is one development I feel reasonably confident about. Customers will be able to operate, adapt, and maintain much more individualized Business Central solutions with significantly less help from Microsoft partners than they need today. They will be able to make changes themselves that previously required a developer. They will automate processes, create extensions, and adapt their systems without necessarily starting a traditional development project. And maintaining those changes through future Business Central releases should become considerably easier.
That doesn't mean partners will become unnecessary. But I believe customers will need us for different things. They will still need people who understand business processes, who can help them organize their data, who can challenge requirements, and who can guide them through complex decisions. They will need someone who understands how the different parts of their business fit together and who can help them avoid creating a collection of individually optimized processes that make absolutely no sense when viewed as a whole.
In fact, the easier it becomes to develop functionality, the greater the temptation will be to develop things that should perhaps never have been developed in the first place. And that brings us back to governance.
The ability to produce software quickly does not automatically mean that the resulting software is useful. Somebody still needs to understand the business well enough to distinguish a good idea from an expensive mistake.
What I took home from Paris
Looking back at Directions EMEA 2026, I am extremely happy with what we achieved. Almost 3,400 participants, a fantastic international community, an enormous amount of content, and countless interesting conversations. And yes, Paris probably helped a little.
But what stays with me most is the feeling that our industry is approaching a period of fundamental change. I don't believe Microsoft partners will disappear, and I don't believe all ERP projects will suddenly become tiny. I do believe that many of the activities we have traditionally charged customers for will require significantly less effort, and that we will have to find new ways of creating value.
We will need to become better at understanding our customers' businesses, helping them define processes, improving data quality, and establishing governance that actually works. We will probably spend less time producing software and more time helping customers decide what software they really need. Some partners will adapt quickly. Others will take longer, and some may discover that their existing business model no longer works particularly well.
As for Directions, I am very curious to see how the community develops. Perhaps we will have more partners, perhaps fewer. Perhaps the companies attending will be smaller, perhaps completely new types of businesses will become part of our ecosystem. At this point, I wouldn't want to place a large bet on any particular scenario.
But after almost thirty years in the ERP business, I find it rather fascinating that we may be moving towards a world in which developing software is no longer the most difficult or expensive part of an implementation. And perhaps, after all these years, we are finally beginning to understand something that should have been obvious from the beginning.
The most important part of an ERP project was never the ERP system itself. It was always the business.
See you at the next Directions EMEA. I'm curious to see how much of this will still make sense by then.
Stay on top of things without tracking everything yourself.
Once a month, Frank Maier puts into context what is moving in the ERP world. Plus the invitation to the next live webinar.
About one email a month. Unsubscribe at any time with one click. Privacy policy
