One Version changes what customising means. The extension model, the order in which you should reach for configuration, Power Platform and code, and why regression testing becomes a permanent activity rather than a project phase.
Every ERP eventually meets a requirement that configuration cannot satisfy. What happens next is where implementations diverge most sharply, and where the habits people bring from older systems cause the most expensive damage.
Every customer runs the same code base. Microsoft ships four service updates a year, customers must take at least two, and one pause is available at a time.
When a requirement cannot be met out of the box, work through these in order. Each step down costs more to keep current than the one above it.
Development happens in a development environment, in Visual Studio, against a model that belongs to the customer or partner. Source control holds the code, as it would for any software. A build pipeline compiles it and produces a deployable package — a versioned artefact. The package is applied to a sandbox environment for testing.
Under a self-hosted ERP, testing is a project activity: you test before go-live, then again before each upgrade every few years.
If your current system has been customised over many years — and it almost certainly has — those customisations need decisions, not assumptions.
Most of what makes a D365 implementation succeed is functional work: understanding the business, designing the organisation and finance model, configuring, testing, and deciding which gaps are real. Very little of it requires code.
The extension model exists to keep a continuously updated system maintainable, and it changes what "customising" should mean.