An AEM build or migration gets scoped in three ways and priced in one. Someone pulls a day rate for an agency, a day rate for an independent contractor and a salary for a permanent hire, lines them up, and picks the smallest number. That comparison is close to useless — at current London and New York market rates, an independent AEM contractor and a fully loaded in-house developer land in roughly the same place per productive day. The numbers that actually separate the three options are how fast the person is useful, how small an engagement they will accept, and who still understands your component library eighteen months after go-live.
The day rate is the least decisive number
Start with what the market publishes. The median advertised contract day rate for AEM skills in London is £548, against a UK-wide median of £500 with the top decile at £710. The median advertised permanent salary for a UK role requiring AEM is £80,000.
Put those side by side and the contractor looks expensive — until you remember what the salary excludes. Employer national insurance, pension, equipment, software, management overhead, recruitment cost, holiday, sick leave and the weeks of the year where a permanent developer is in planning, training or someone else’s incident. In the US the loading is measurable: benefits account for 31.5% of total employer compensation costs for full-time private industry workers, so a New York AEM developer averaging $130,278 a year costs materially more than the headline before you have paid for a single sprint of output.
Once you have grossed up the salary and netted down the working year, the gap between a contractor’s day rate and an in-house developer’s fully loaded cost per productive day narrows to something you should not be making a hiring decision on. Agency rates sit above both — but an agency is not selling you a developer, it is selling you a delivery team with an architect, a QA function and someone whose job is to notice when the content model is wrong. Compare like for like or do not compare at all.
The cheapest option on a spreadsheet and the cheapest option on a project are rarely the same option.
What the three options actually look like
| Full-service agency | Independent contractor | In-house hire | |
|---|---|---|---|
| Cost basis | Blended team rate, above single-contractor rates | London median £548/day; UK median £500/day, top decile £710 | UK median salary £80,000; NYC average $130,278 plus ~31.5% benefits loading |
| Minimum engagement | Statement of work, typically a phase or full programme | Days to weeks; easily extended | Permanent headcount — no floor below a full role |
| Ramp time | Weeks — discovery, environment access, multiple people onboarding | Days — specialists who have done the same migration pattern before | Months — notice period, then AEM-specific ramp |
| Knowledge after go-live | Lives with the agency; retained only through a support contract | Leaves with the contractor unless you plan handover | Stays — median US tenure with one employer is 4.1 years |
| Best at | Multi-workstream programmes, full site rebuilds, when you need delivery accountability | Fixed-scope upgrades, migrations, unblocking an in-flight build, covering a specific gap | Steady-state run, authoring support, incremental roadmap |
| Fails at | Small scopes, surgical fixes, anything under its commercial floor | Carrying a whole programme alone; long-run ownership | Cold-starting a migration on an unfamiliar version |
Ramp time is where the money actually goes
AEM punishes generalists. The difference between someone who has shipped Edge Delivery Services, done a 6.5-to-Cloud-Service migration and fought through a dispatcher caching problem, and someone who is very good at Java and reading documentation, is measured in weeks of your calendar — not in their rate.
The ramp profiles are genuinely different:
Agency
An agency ramps a team, not a person. That means discovery, environment provisioning, access requests and several onboarding curves running at once. It is the slowest start of the three, and the most robust once it is moving — nobody on your side has to hold the plan in their head.
Contractor
A contractor who has done your specific migration pattern before can be productive inside the first week, because the work is pattern recognition rather than discovery. This is the whole case for contract AEM capacity, and the market reflects it: 76 UK contract vacancies cited AEM in the six months to 14 October 2026, with contract demand running at a similar scale to permanent demand. Companies are not using contractors as a last resort — they are using them because a dated, scoped piece of AEM work is exactly what a contractor is built for.
In-house hire
Add the notice period to the AEM ramp. A permanent developer who starts in three months and is confident in your codebase a month later has consumed a third of a year before contributing to a migration that was supposed to ship this year. That is a fine trade for steady-state ownership and a poor one for a deadline.
If the migration has a date on it, ramp time is the only cost line that matters. Everything else is negotiable.
Minimum engagement size decides more than you expect
Most AEM decisions are made badly because the work does not fit the commercial shape of the supplier.
Agencies have a floor. Below a certain scope the overhead of a statement of work, a discovery phase and an account structure exceeds the value of the work. Ask an agency for three weeks of component refactoring and you will get either a polite no or a price that makes the no implicit.
A contractor’s floor is days. That makes them the only realistic option for the long tail of AEM work: a version upgrade, a dispatcher rewrite, a content fragment model redesign, an accessibility remediation pass, covering a permanent developer’s parental leave. It also makes them the right answer when you genuinely do not know how big the job is yet — you can buy two weeks of assessment before committing to a programme.
An in-house hire has no floor at all, only a ceiling. You cannot hire 40% of a developer. If the AEM work on your roadmap does not fill a role for the next few years, a permanent hire is the most expensive way to get it done — and the hardest to reverse.
The practical test: write down the AEM work you can name for the next twelve months. If it fills a programme, talk to an agency. If it fills a person indefinitely, hire one. If it is a defined project with an end, a contractor on the /adobe network is the shape that matches.
Retained knowledge has a shelf life in every model
The strongest argument for permanent AEM headcount is that the knowledge stays. It does — for a while. Median tenure with one employer in the US is 4.1 years, and specialist platform developers in a hot skills market tend to sit under the median, not over it. A permanent hire is a four-year lease on institutional knowledge, not a freehold.
That reframes the comparison usefully. None of the three options retains knowledge by default — each one retains it only if you build for it:
- Agency: knowledge lives in their delivery team and their documentation. You keep it by contracting for documentation as a deliverable, insisting your people sit in the architecture decisions, and owning the repository from day one.
- Contractor: knowledge leaves on the last day unless handover is written into the engagement. Pair them with whoever will run the platform afterwards, make the handover a milestone with a date, and require architecture decision records rather than a verbal walkthrough.
- In-house: knowledge stays in one head, which is its own risk. One developer who understands your AEM instance is a single point of failure dressed up as continuity.
The same logic applies across platform hires — we have written about owning your platform expertise rather than renting it indefinitely, and about blending a systems integrator with in-house capability. AEM is the same problem with different acronyms: the question is never whether to use external help, it is what you keep when the help leaves.
How the three combine
In practice the teams that ship AEM migrations cleanly rarely pick one. The pattern that works:
| Phase | Who | Why |
|---|---|---|
| Assessment and scoping | Contractor, 2–4 weeks | Cheap, fast, no commitment before you know the size of the job |
| Build or migration | Agency for multi-workstream programmes; two to three contractors for a single-site migration | Matches delivery shape to scope rather than to supplier type |
| Handover | Contractor plus your permanent hire, overlapping | Knowledge transfer with a date on it, not a wiki page written on the last Friday |
| Run and roadmap | In-house | Steady-state work that justifies a permanent role |
The sequencing matters more than the suppliers. Hiring the permanent developer first and asking them to lead a migration on an unfamiliar version is the most common and most expensive mistake — you pay a four-month ramp before the migration starts. Hiring an agency for a three-week dispatcher fix is the second.
The questions that settle it
- Does the AEM work have an end date? If yes, you are buying a project, not a person.
- Will the work still exist in two years? If no, do not create a permanent role for it.
- Who runs the platform the day after go-live? If the answer is nobody, fix that before you choose a supplier.
- Is the blocker capacity or capability? Capacity is a contractor problem. Capability is a hiring and training problem, and no day rate solves it — we have written about that distinction.
- What would a three-month delay cost? That number, not the day rate, is what you should be optimising against.
Run those five and the day rate stops being the decision. It becomes what it always was — a line item you compare after you have already worked out which shape of help the work needs.