You're already using Microsoft: Should you adopt a second platform?

The answer isn't "no." It is: first, take a look at what you're actually buying, because it's not software. It's a second pillar.

What an integrated suite is, in its own words

Odoo describes itself as “a suite of open-source business applications,” whose value proposition is to be “both very easy to use and fully integrated.” It consists of about 50 core applications, supplemented by thousands of contributions, which can be added one by one as needs evolve.

That’s an accurate description, and that’s exactly the point. A fully integrated suite is a platform. It provides its own user management, its own permissions, its own database, its own update logic, its own backups, and its own capabilities.

If you're already using Microsoft 365, you already have one. So the decision isn’t “which tool is best,” it’s “how many platforms can my company support.”

The cost of the second base—which is never included in the estimate

License costs are generally the smallest expense, and that's what makes the comparison misleading. What really adds up is the duplication:

• Two directories. An arrival, a departure, or a change in position must be updated in both locations. Anything not updated in both locations becomes an orphaned account—the most common and frequent security flaw.
• Two models of rights. Who sees what is determined twice, based on two different logics, and is verified twice during an audit.
• Two backup and recovery plans. Twice the question, “In the event of a disaster, where do we start over?” and twice the need to have tested it.
• Two sets of skills. The ones that underpin your current foundation aren’t applicable to the other. In French-speaking Switzerland, the talent pool is different, and so are the costs.
• Two areas to monitor. Each exposed platform is a gateway, and each requires its own patch tracking.

None of these items appear in the working out of the problem. All of them appear in the second year.

Note: This reasoning applies both ways. A company whose core business already runs on an integrated suite would be just as wrong to add a second platform for a one-time need. The principle isn’t “Microsoft”; it’s “one platform, and we build on top of it.”

The mechanism that slows down development, regardless of the publisher

This is the most misunderstood point, and it isn't directed at anyone in particular.

When you customize an integrated product, you modify a core component shared by all its modules. Each customization creates a dependency between your work and a specific version of the product. With the next update, you have to verify that each customization still works—and the cost of this verification increases with the number of customizations. The more you develop, the more expensive each version update becomes. It’s simple math.

This isn't a flaw on the part of a software vendor—it's simply the nature of an integrated product. We've just provided an example from Microsoft itself, involving a customer relationship management software product that is no longer supported, where the customization layer accounts for the bulk of the deployment effort. The mechanism is the same.

The practical implication: if you need to do a lot of development, an integrated product is the wrong place to do it. A tool built alongside the foundation, connected via its own interfaces, does not inherit this debt.

Situations in Which a Second Platform Is Justified

They exist, and we need to call them out honestly:

• Your profession has a standard, comprehensive need that is addressed by the suite, and you agree to follow its approach without customizing it;
• You haven't established a foundation yet, and the choice is still open;
• License cost constraints are a major factor at your scale, and you have quantified the corresponding operational overhead.

The common thread: the second platform makes sense when adopted as is. It makes little sense when adopted with the intention of transforming it.

Five Questions to Ask in a Meeting

1. Will this suite replace an existing tool, or will it be added to the existing one?
2. Who will manage the accounts, and how will an employee's departure be handled at both locations?
3. How many adaptations are planned for the first year?
4. Who handles the version updates, how often, and who verifies the changes?
5. Does what we want to build already exist in what we pay for?

The fifth point often comes as a surprise. Some of the requirements cited as justification for a new platform—an application form, an approval workflow, shared tracking, a dashboard—can be handled within the existing environment, whose licensing model, incidentally, has shifted: it’s no longer the number of applications that drives the cost, but the number of users.

Our Reading

We do not sell enterprise resource planning (ERP) software, and this article does not advocate one product over another. It advocates an architectural principle: a foundation, upon which we build. When that foundation already exists— and has been paid for, is managed, and is under control—the burden of proof lies with whoever proposes installing a second one.

Lambert Consulting builds tools on top of the foundation you already have and connects them to existing ones—including those not made by Microsoft. When the right solution is to build nothing at all and simply share information between your current tools, that’s exactly what we offer.

Sources

• Rates Power Apps
• Environments Power Platform
• Odoo — Company Overview