Practice 01
Our anchor practice. We implement Business Central, migrate NAV installations into it, fix the ones that did not land well, and keep them running afterward. Most of our clients are already live when they call us.
Our position
We are not reselling licenses and we are not incentivized to expand your user count. That changes the advice. When the right answer is a configuration change instead of a build, we say so, and it costs us revenue to say so. When the right answer is that your current partner should be fixing this under their existing agreement, we say that too.
What we bring is depth in the application itself. Our senior people have been in this codebase since Navision, through NAV, into Business Central and across the update waves since. That matters most in the places where BC is opinionated: posting routines, dimensions, costing, item tracking, warehouse activities and the interaction between them. Those are the areas where an inexperienced customization causes damage that only surfaces at year end.
Capabilities
Ordered by demand. The first three account for most of the hours, and the last one is how Microsoft Partners engage us.
New Business Central implementations, plus additional entities, countries and legal entities added to an existing tenant. Chart of accounts, dimensions and posting setup designed so reporting works on day one instead of being rebuilt in year two.
The full path off Dynamics NAV, starting with a code review rather than a data conversion. Every customization classified as standard, rebuild or retire before anything is written.
For environments that are live and unhappy. We audit the configuration and the code, quantify what is actually costing time, and work a prioritized list. Frequently this is slow posting, a broken costing setup, dimension design that makes reporting impossible, or an extension doing something the base application already does.
Custom functionality built as proper extensions, upgrade safe, source controlled, and documented well enough that the next consultant can read it. We do not modify base objects and we do not leave you dependent on us to understand your own system.
Business Central connected to the rest of the stack. Warehouse and scanning systems, e-commerce, EDI, payment providers, CRM, shop floor data collection, banking and third party logistics. Built with retry handling and logging, because integrations fail at 2am and somebody has to be able to see why.
Getting off an old version, and making the twice-yearly waves boring. We test extensions against preview builds, fix breaks before they reach production, and give you a short written note on what changed that matters to your users.
Named consultants on a monthly block of hours. They keep the documentation of your environment, so requests do not start from zero. Escalation paths that end with a person who can read the code.
Senior BC developers and functional consultants supplied to Microsoft Partners, working inside your process and under your brand.
Implementation
The decisions that decide whether a Business Central implementation ages well are all made in the first few weeks, and almost none of them are visible at go-live.
Most of the rescue work we are called into traces back to a setup decision, not a bug. A chart of accounts numbered for the old system. Dimensions added later, so the first two years of history cannot be reported the same way as the third. Posting groups built around one warehouse before anyone asked what happens when there are four. Item tracking switched on without deciding who is responsible for the lot at each step.
We design that layer deliberately and write down why each choice was made. New entities, additional countries and extra legal entities added to an existing tenant follow the same discipline, because a rollout that does not match the original design is how a single tenant ends up with three different ways of doing the same thing.
Migration
The reason NAV migrations stall is almost never the data. It is that a decade of modifications live in the base objects, nobody left has full knowledge of what they do, and the last honest estimate anybody got was a range wide enough to be useless.
We take that unknown out first. Before any conversation about timelines, we inventory every modification, every report, every integration and every scheduled job, and we tell you which of them Business Central now does natively. On most NAV systems that is a meaningful share of the list, and the project gets smaller the moment you can see it written down.
01
Every modification in the current system, catalogued with what it does and who still depends on it. Delivered as a document you own, whether or not we do the migration.
02
Each item marked standard in BC, rebuild as extension, or retire. You approve the list. This is where the project scope is actually set, and where most of the savings are.
03
Extensions developed and validated against a copy of your real data. Users test their own transactions in their own company, not a demo dataset.
04
A dated cutover plan, parallel running where the risk warrants it, a rollback that has been rehearsed, and our people present through your first month end close in the new system.
The three-way classification applied to the categories we find in almost every NAV installation. The proportions differ by system. The categories do not.
| What we find in NAV | Usual classification | Why |
|---|---|---|
| Base object modifications | Rebuild as extension | Cannot come across as written. Rebuilt against events and interfaces so update waves stop breaking them. |
| Workarounds for missing features | Standard in BC | A share of every NAV modification list is now base functionality. These are retired and reconfigured rather than rebuilt. |
| Custom reports and layouts | Rebuild or replace | Many are duplicates of each other or of a standard report. The surviving set is usually much shorter than the original. |
| Point-to-point integrations | Rebuild as API | Direct database and file-drop interfaces are replaced with proper API integration, with logging and retry handling. |
| Scheduled jobs and batch routines | Review individually | Some are load-bearing, some have been failing silently for years. Both are common and both need to be found before cutover. |
| Features nobody has used in years | Retire | Carrying dead functionality forward is pure cost. If nobody can name the user, it does not come along. |
Optimization and rescue
We come in behind other people's implementations as often as we do our own. The work starts with reading what is actually there, not with a proposal to start over.
An audit takes the complaints your users are already making and separates them into three lists: configuration, code, and business process wearing a system costume. That split matters, because the three have very different costs and only one of them is expensive.
What comes back is a prioritized written plan with effort against each item, ordered by what it costs you today rather than by what is technically interesting. You are free to take that plan to your existing partner. It is written to be actionable by whoever holds the contract.
01
Configuration, extensions, integrations and the actual transaction volumes. Plus the complaint list from the people using it.
02
Each finding sized by what it costs in hours or risk today, with the effort to fix it beside it. Ordered by return, not by novelty.
03
Fixes delivered in priority order into a sandbox first. You can stop after any item, and the plan is yours either way.
Build
Custom functionality built as proper extensions, and Business Central connected to everything around it. The standard we hold this to is that the next consultant can read it without calling us.
Written in AL to AppSource technical standards whether or not it is ever published there.
The systems we are most often asked to put on the other end of a Business Central interface.
Keeping it running
Two release waves a year is only a problem if nobody looks at them until users do. The work here is unglamorous and it is what keeps the rest of the list short.
Getting off an old version, and making the twice-yearly waves boring.
Named consultants on a monthly block of hours, who already know your system.
For Microsoft Partners
Partners bring us in when the pipeline lands faster than hiring does. We work under your project manager, in your repositories, to your standards and documentation conventions, and we stay behind your brand with the end client for as long as the engagement runs. We do not solicit your clients, during or afterward.
01
Senior AL capability dropped into a defined piece of scope, working in your branch and to your review process.
02
Configuration, workshops and user testing through a rollout phase, presented as part of your team.
03
An independent read of a build before it reaches the client, or a rescue on a project that has drifted.
Contract structure is whatever suits you, hourly or fixed scope, direct or through your paper.
Experience
30+
Years of combined Dynamics experience
Navision, through NAV, to Business Central.
20+
International projects
Across multiple regions and compliance regimes.
27+
Clients served
Both direct end users and Microsoft Partners.
100%
Client satisfaction to date
The standard we hold ourselves to on every engagement.
Next step
The fastest way to start is to send the actual list of complaints from your users. We will tell you which items are configuration, which are code, and which are the business process rather than the system. There is no charge for that read.
