Join me as I visit Microsoft Development Center Copenhagen and chat with the team that builds Business Central. Check it out:
In this special episode, Erik takes us on a behind-the-scenes tour of Microsoft’s Business Central headquarters in Denmark. Armed with a camera (but no tripod — he was on vacation!), Erik interviews key members of the BC team, from the chief architect to developers working on the server, UI, dev tools, and application layers. Along the way, he asks community-submitted questions from Twitter about everything from table extensions to .NET Core migration.
Inside Microsoft Denmark: The Business Central Headquarters
Erik traveled a thousand kilometers to visit the Microsoft Development Center in Copenhagen — the home of Business Central development. In a fun twist, the entrance to the building is literally a large blue shipping container, proving that when Microsoft says they use containers, they mean it in every sense of the word.
Meet the Team
Vincent — Chief Architect for Business Central
Vincent has been working with Business Central for over 10 years. His team spearheads the next generation of the product’s architecture and tackles the hardest problems in the organization. Before becoming chief architect, he worked on the client team during the era when mobile clients (tablet and phone) were introduced.
Vincent originally studied in France, came to Denmark for an internship to “expand his horizons,” met his wife, and 30 years later is still there. Before Microsoft, he spent 11 years building software for medical analysis equipment.
Jacob — UI Design Team
Jacob is part of the team that designs the user interface for Business Central. His team — comprising visual designers, researchers, and interaction designers — conceived the original Business Central icon. The inspiration came from an unexpected place: the New York subway map.
The idea was that Business Central represents systems connected together, like trains moving from station to station in a coordinated and synchronized fashion. From a visual design perspective, the New York metro map is considered a fantastic piece of design, and that association became the foundation for the BC icon. The original monochrome version was later refreshed with colors during a branding update.
Jacob holds a PhD in Computer Science from the IT University of Copenhagen and joined Microsoft through a university cooperation project that gave him connections leading to a full-time role after graduation.
Ihor — App Team (System Application)
Ihor works on the system application, primarily developing new modules. He’s responsible for features like the User Setup Wizard that updates users from Microsoft 365 — the tool partners use when licenses don’t match users and you need to pull an update.
Microsoft is his first full-time job, with previous internships at SAP (in Germany) and Samsung. He studied Computer Science at Taras Shevchenko National University in Kyiv, Ukraine. A LinkedIn recruiter from Microsoft contacted him about working on Dynamics products in Denmark — a classic example of how LinkedIn profiles can open doors.
Mads — Server Team
Mads works on what many in the community remember as the NST (Nav Service Tier). His team is responsible for running AL code and everything necessary to support it — the record API, functions like SelectLatestVersion, Commit, and all the foundational runtime functionality.
Notably, Mads was one of the main people behind Partial Records — it was his design that won out and his implementation. He joined Microsoft as a student worker while studying at the University of Copenhagen, after a LinkedIn recruiter initially reached out about an internship in America. He opted for the student job in Copenhagen instead, and the rest is history.
Stefan — Developer Tools Team
Stefan is an engineering manager in the developer tools team with 14 years at Microsoft. His team is responsible for the AL Language extension in Visual Studio Code and the deployment pipeline — packaging AL components and pushing them to the server.
He shared a fascinating technical detail about the AL compiler:
The AL compiler is essentially a transpiler. It parses AL syntax, builds the tree structure and dependency graph, then converts the code into C#, which is then compiled into standard .NET assemblies (DLLs). Those assemblies are what actually execute on the server. So when you write AL code, it ultimately runs as true compiled binary code through the .NET runtime.
Stefan’s career at Microsoft has spanned application integration (Outlook integration, Employee Portal), SharePoint/Office integration, the platform/runtime team, server management and cloud orchestration, and now developer tools.
Key Questions from the Community
Onboarding Without Partners
Vincent was clear that Microsoft has no intention of removing partners from the loop. The onboarding investments are driven by the realization that getting started with an ERP system can be painful and lengthy. Microsoft has a mantra across SaaS products: “Five seconds to sign up, five minutes to wow.”
For ERP, this is understandably harder. Vincent suggested a more realistic goal might be: five seconds to sign up, five minutes to wow, and five days to first transaction. The onboarding platform is customizable, and Microsoft strongly encourages partners to adopt these capabilities and provide their own onboarding content for their solutions.
How Is the Team Organized?
Business Central development is broadly split into two larger groups:
- App — working primarily on the application layer
- Platform — working on the server, client, and the less visible “control plane” that manages the service in Azure
Within these groups, teams are typically five to six people. The control plane handles everything from provisioning new instances when customers sign up, to upgrades, to monitoring — a significant amount of machinery beyond what on-prem users see on the DVD.
How Far Ahead Is the Team Working?
The leadership team meets twice a year for offsite discussions about long-term strategy — thinking about 2024 and beyond (at the time of recording). However, these are vision and strategy discussions, not feature-level planning. If you walked up to any developer in the office, they’d be working on the next wave (version 21 at the time).
The process flows from strategy to backlog to prioritization. With the six-month release cadence, if something doesn’t make it into the current wave, it’s likely to land in the next one.
Table Extensions: Why Separate Tables?
This was one of the most popular community questions. When you add a field via a table extension, it’s stored in a separate SQL table — a design many developers find frustrating due to performance implications.
Vincent explained the history: Extension v1 (circa 2017) actually did add fields directly to the base table. But they discovered problems, mostly related to upgrades. When Microsoft needed to upgrade the service and made internal changes to extended tables, it created complications. Extension v2 moved to separate tables, which cleanly isolates extension data from the base table.
However, Vincent revealed that they’ve been actively discussing going back to the original model — adding fields directly to the base table — with new ideas for handling the upgrade issues. Nothing is set in stone, but if they can find a way to make it performant while still addressing upgrade concerns, they might revisit that design.
Moving to .NET Core
At the time of recording, the Business Central server (NST) ran on .NET Framework 4.8, which from Microsoft’s perspective is essentially legacy. The entire .NET ecosystem has moved to .NET Core.
Vincent confirmed that Business Central on .NET Core is coming — and soon. The migration had been underway for about two years. The approach was both bottom-up and top-down through the dependency graph: converting components at the top to .NET Standard (a subset compatible with both Framework and Core) while simultaneously converting components at the bottom, until both ends meet and they can “flip the big switch.”
One of the biggest blockers was WCF (Windows Communication Foundation), which handled all internal communication between the client services and the NST. There is no WCF on .NET Core, so the entire communication protocol had to be replaced. Vincent confirmed that yes, internally, they were running SOAP-based communication. This was being replaced with a new, faster protocol stack.
While running on Linux isn’t an explicit goal, it could be an “interesting side effect” of the .NET Core migration. The primary motivation is moving to the latest platform and benefiting from the significant performance improvements in .NET Core.
Interestingly, the AL compiler and VS Code extension already run on .NET Core — you can actually run the AL extension on macOS, though Microsoft doesn’t officially publish a Linux-compatible version since they don’t test it.
Biggest Mistake Taking BC to the Cloud
Vincent reflected that the first attempt at cloud wasn’t a true SaaS solution but rather a PaaS model (around NAV 2017). Partners would upload their complete solution — executables and database — through a portal, and Microsoft would provision it in the cloud. Customers on that model experienced performance issues and other challenges.
In hindsight, going directly to SaaS might have been better, but the platform and Azure technologies (Service Fabric, Azure SQL) may not have been mature enough at that time.
The biggest ongoing technical debt is the monolithic NST. Born in the on-prem world, it became a “Swiss Army knife” handling data, AL runtime, security, caching, reporting, and more. The long-term vision is to break it into standalone microservices, each with a clear area of responsibility. For example, licensing has already been moved to a separate cloud service, and reporting is being extracted as well.
The ultimate architectural vision: evolve the codebase so that you couldn’t distinguish it from a product that was born in the cloud — even though it still shares a codebase with the on-prem version.
Bonus: Using the Camera in Business Central
Fitting the theme of bringing a camera to Microsoft, the source code accompanying this video demonstrates how to use the camera functionality in Business Central. Here’s a simple table to store photos:
table 50108 photo
{
fields
{
field(1; P; Code[20])
{
}
field(2; Picture; Blob)
{
Subtype = Bitmap;
}
}
keys
{
key(PK; P) { }
}
}The page provides two different approaches for capturing photos. The first uses the Camera codeunit, which is the simpler, recommended approach:
action(test)
{
caption = 'Clicky Codeunit';
ApplicationArea = all;
Promoted = true;
PromotedCategory = Process;
PromotedOnly = true;
trigger OnAction()
var
Camera: Codeunit Camera;
InS: InStream;
OutS: OutStream;
FileName: Text;
begin
if Camera.IsAvailable() then begin
if Camera.GetPicture(InS, FileName) then begin
Rec.Picture.CreateOutStream(OutS);
CopyStream(OutS, InS);
Rec.Modify();
end;
end;
end;
}The second approach uses the Camera page directly, which gives you more control over settings like encoding type, quality, and whether editing is allowed:
action(test2)
{
caption = 'Clicky';
ApplicationArea = all;
Promoted = true;
PromotedCategory = Process;
PromotedOnly = true;
trigger OnAction()
var
Camera: Page Camera;
InS: InStream;
OutS: OutStream;
FileName: Text;
begin
if Camera.IsAvailable() then begin
Camera.SetAllowEdit(true);
Camera.SetEncodingType("IMage Encoding"::PNG);
Camera.SetQuality(10);
Camera.RunModal();
if Camera.HasPicture() then begin
Camera.GetPicture(InS);
Rec.Picture.CreateOutStream(OutS);
CopyStream(OutS, InS);
Rec.Modify();
end;
end;
end;
}Both approaches check IsAvailable() first (the camera is only available on mobile devices), capture the image as a stream, and store it in a Blob field. The page-based approach offers additional control with SetAllowEdit, SetEncodingType, and SetQuality for fine-tuning the capture experience.
Summary
This behind-the-scenes look at Microsoft’s Business Central headquarters revealed several key insights:
- The BC team is organized into App and Platform groups with small, focused teams of five to six people
- The Business Central icon was inspired by the New York subway map — representing interconnected systems
- The AL compiler transpiles AL code to C#, which is then compiled into standard .NET DLLs
- Table extension storage in separate SQL tables was a deliberate v2 design choice, but the team is actively discussing reverting to inline fields with improved upgrade handling
- The migration to .NET Core was well underway, with WCF replacement being the final major blocker
- The long-term architectural vision is to decompose the monolithic NST into focused microservices
- The onboarding goal is “five seconds to sign up, five minutes to wow, five days to transact”
- The team works one wave ahead, with strategic planning extending years into the future
Erik noted that all interviewees happened to be male, which was not intentional — the filming took place on a single day during summer vacation with many team members working from home, and the lineup did not represent the true diversity of the BC team. A big thank you to Microsoft for opening their doors and to everyone who stepped in front of the camera with little to no warning.
