EN
An Umbraco site is rarely on its own. There is a CRM attached, a recruitment system, a consent tool, an analytics suite, a feedback platform or the client's own planning system. The question is nearly always the same: can Umbraco connect to it, and what does that cost? The answer to the first is yes — Umbraco is .NET, and anything with an API is reachable. The answer to the second is below, with figures from two real estimates.
From two recent estimates for sites with several external integrations — per type of system, excluding any additional work by the vendor:
| Type of integration | What happens | Indication |
|---|---|---|
| Consent and cookie management | Tying consent to what actually loads | ±2 hours |
| Analytics and tag management | Verifying measurement and tags, including their dependency on consent | ±2 hours |
| Feedback or review platform | Checking the widget, its triggers and the hand-off | ±2 hours |
| Recruitment or ATS system | Pulling vacancies, pushing applications, reporting statuses back | ±4 hours |
| Planning system over SOAP | Older APIs with their own schemas and error handling | ±4 hours |
| Calculator or bespoke tool | Walking input, calculation and result end to end | ±4 hours |
| Transactional email | Checking delivery, sender domain and spam score | ±4 hours |
So two to four hours per integration. That is the line everyone expects — and it is the smallest one.
In those same two estimates the phase "integrations and testing" came to 40 to 44 hours in total. It broke down like this:
| Item | Hours |
|---|---|
| Testing the integrations themselves (3 to 5 of them) | 12 to 14 |
| Internal test across the whole site | 16 to 18 |
| Writing the test scenario for the client | 8 |
| Guiding the acceptance test | 4 |
More than two thirds of the budget goes into proving the rest of the site still works. That is not overhead, it is the point: an integration that works in isolation tells you nothing as long as you do not know whether the form around it still submits, whether the consent tool still releases the script and whether the email still arrives. An integration rarely fails loudly — it fails quietly, and only shows up in the numbers weeks later.
Moving from an older Umbraco version to the current one makes integrations the largest risk — larger than the upgrade itself. Three things come up in practice: APIs that changed while the site stayed on an old version, credentials that are documented nowhere and exist only inside an old configuration, and integrations nobody remembers still using.
That is why "check the integrations" sits in our inventory phase, before the plan is final. What that means for the total budget is on what does an Umbraco migration cost; how such a project actually went is in our case study on migrating from Umbraco 10 to 17.
In practice, yes. Umbraco is .NET, so anything offering an API is reachable: modern REST and JSON APIs, older SOAP services with their own schemas, webhooks and file exchange. If a system has no API at all, that is the limiting factor — not Umbraco.
During a migration or upgrade we allow 2 to 4 hours per integration to test it, depending on how much runs through it. Building a new integration depends on the vendor's API: well documented and modern goes quickly, an undocumented SOAP service costs more. We estimate that case by case and list it separately, so you can see where the money goes.
Not in the code and not in the repository, but stored per environment and loaded only at run time. Each environment has its own values, so a test never reaches a vendor's production API and a key does not travel along in a copy of the site.
They are each reviewed and retested. It is the largest item in a migration budget, larger than the upgrade itself: more than two thirds of the time goes into testing. See what does an Umbraco migration cost for the full breakdown.
Yes. A submission can go to a CRM, a mailbox and an API at the same time, each as its own step with its own handling. If one step fails, that is visible per submission instead of the submission quietly disappearing.
Failed calls are logged and traceable, and the environments are monitored externally for availability. The acceptance test at delivery remains the most important part: that is where each integration is confirmed to work, and it is the baseline you measure against later.