Skip to content

Solutions

Deployment & configuration

From an empty environment to a system your team uses on Monday.

The problem

Why this is harder than it looks

Open-source platforms are free to download and expensive to get wrong. The install is an afternoon; the configuration is the project. Most failed deployments we are called in to rescue were not defeated by the technology — they were defeated by a chart of accounts nobody agreed, a workflow modelled on how the old system worked, or an environment built by hand that nobody can reproduce.

Method

How we run it

  1. Discovery and fit assessment

    We map your processes against what the platform does as standard, and write down the gaps: configure, extend, or change the process. You get that document whether or not you proceed with us.

  2. Environment build

    Development, test and production, defined as code so they are reproducible. A hand-built environment is a single point of failure with a person’s name on it.

  3. Configuration

    The substance of the work. Company structure, workflows, permissions, approval routing and master data, configured against the fit assessment.

  4. Extension where genuinely needed

    Built through the platform’s supported extension points, versioned and tested against upstream releases. Never a fork.

  5. UAT and go-live

    Scripted acceptance with your people and your data, then a planned cutover with a rollback position and a defined hypercare period.

What you get

  • Written fit assessment, including the gaps and what we recommend doing about each
  • Reproducible dev, test and production environments defined as code
  • Configured platform, documented decision by decision
  • Any extensions, with source, tests and build pipeline — all of it yours
  • Runbooks covering deploy, backup, restore and upgrade
  • Verification output from every environment
  • Training for administrators and for end users, separately

What is out of scope

Stated here rather than discovered in month three.

  • Forking or hand-patching upstream code. It cannot be supported under an SLA and it blocks your upgrade path
  • Cleansing your legacy data. We will profile it and tell you precisely what is wrong; correcting it needs the people who know what it should say
  • Business process re-engineering as a discipline in its own right. We will flag processes that fight the platform, but we are not a change-management consultancy
  • Ongoing operation, unless you take managed hosting or support

What it costs

Time and materials against an agreed estimate, or fixed price with change control for a tightly scoped piece of work.

See the rates

Questions

Things people ask

Can you work to a fixed price?

For scoped work, yes, with change control. We will not fix-price a project before discovery, because the estimate would be a guess with a decimal point on it. Most clients take discovery as a fixed-price piece and then decide.

What if the platform cannot do something we need?

You find out during discovery, in writing, before you have committed to the build. The options are then: change the process, build an extension at a stated cost, or do not proceed. We have recommended the third of those.

Do we need our own technical team?

Not if you take managed hosting — we run it. If you want to run it yourself, you need someone comfortable with Linux and the platform’s administration. We train them and hand over the runbooks.

How long before we are live?

A single-company ERPNext deployment with straightforward processes is typically 25–40 consultant days spread across three to four months of elapsed time. The elapsed figure is usually governed by your team’s availability for UAT, not by ours.

Talk to someone who will tell you if it is a bad fit

A scoping conversation, not a sales call. We will tell you what the platform does today, what it would cost, and where the risk sits.