AEM Implementation Partners: How to Choose One — and How DWAO Delivers

Here's a pattern we've seen enough times to call it a law: ask a company two years after their AEM launch what they'd do differently, and nobody says "we should have picked different software." They talk about the implementation — the content model that never matched how marketing thinks, the templates nobody can author in, the integration that got "descoped" and then haunted every quarter since. The platform survives; the implementation decisions are forever.

That's why choosing between AEM implementation partners deserves more rigor than most procurement processes give it. This is DWAO's guide to the decision — what the project actually involves, where it goes wrong, what to demand — and, because we're one of the partners you might evaluate, an open look at the playbook we run. Judge us by it.

What an AEM Implementation Actually Involves

Strip away the methodology branding and every serious AEM implementation runs through the same six phases. What varies between partners is how honestly each phase gets its due.

1. Discovery and content architecture (weeks 1–4). The phase that decides the project. Content models designed around editorial reality, template strategy, component inventory planned against Core Components, integration contracts drafted. We put our most senior people here because a wrong decision in week two costs fifty times more to fix in month six.

2. Foundation build (weeks 3–8). Environments and Cloud Manager pipelines, dispatcher and CDN configuration, design-system foundations, the first templates proven end to end — authored, published, cached, measured.

3. Feature build (weeks 6–16). The visible middle: components, templates, workflows, in agreed increments demoed as they land. If your partner's demos start in month three, worry.

4. Integration (parallel, weeks 4–16). DAM ecosystems, analytics, personalization, commerce, CRM, search. This is where schedules genuinely slip — third-party systems have their own timelines — so contracts and test stubs come early in our plans, never late.

5. Content migration and authoring (weeks 8–18). Existing content restructured (not just copied) into the new models, and authors trained on the real system while it's still soft. SEO continuity — URL mapping, redirects, metadata parity — is engineered here, because rankings lost at cutover are revenue lost for quarters.

6. Hardening and launch (final weeks). Performance against budgets, security review, load testing where traffic warrants, rehearsed cutover with a rollback path, and hypercare after — sized to the launch's actual risk.

Timelines: a focused single-brand Cloud Service build typically lands in three to six months; multi-site, multi-locale enterprise programs run longer. Anyone promising a full implementation in six weeks is describing a demo install with your logo on it.

Where AEM Implementations Go Wrong

We've audited enough troubled estates to keep an honest taxonomy. Every entry is screenable in advance — which is the point of listing them.

The content model nobody asked editors about. Built to mirror an org chart or a database schema instead of how content actually gets created. Symptom: editors keep asking "where do I put this?" — forever.

Customization without a budget line for regret. AEM will let a partner build anything, and a partner billing by the hour has soft incentives to agree. Every custom component is a small mortgage: build cost now, maintenance and upgrade cost indefinitely. Our rule — and the rule to demand from anyone — is Core Components until your business provably differs.

Integration as a closing chapter. UI progress makes great steering-committee demos while untested integrations accumulate risk. The ERP quirk, the DAM permission model, the SSO edge case: all discoverable in week six, all expensive in week twenty.

Authors meeting the platform at launch. Training scheduled as a hand-off formality produces launch-day helplessness and a support queue that never drains. Authors should be publishing real content on the real system weeks before go-live.

Migration as copy-paste. Old content in new templates, structure and debt intact. A migration is your one cheap chance to restructure and prune; partners who script a bulk copy are spending that chance on nothing.

What Week One With DWAO Actually Looks Like

Because "content-first discovery" is easy to claim, here's the literal first week of our implementation playbook, meeting by meeting.

Monday–Tuesday: the listening tour. Structured sessions with the people the platform must serve — editors walked through their current publishing reality (we time real tasks, with permission, because "publishing takes forever" becomes actionable when it's "publishing takes 47 minutes and 31 of them are the approval workflow"), marketing leadership on what the site must do commercially, developers on the integration landscape and its known dragons.

Wednesday: the content inventory begins. Automated crawl plus human judgment: what exists, what's duplicated, what gets traffic, what legal insists must survive. This runs for weeks, but it starts now because migration scope hides here — and migration scope is where budgets go to be surprised.

Thursday: architecture hypotheses. Our architect sketches two or three content-model candidates against what Monday and Tuesday surfaced — deliberately plural, because model options make workshop conversations concrete in week two the way blank whiteboards never do.

Friday: success criteria, drafted. The yardstick document, in plain language: what measurably better looks like for authors (time-to-publish), for the business (the metrics the site serves), for engineering (deploy cadence, incident posture). You'll sign it in week two, and every scope debate for the next five months gets settled against it — including debates with us.

That's the week. No code, no licenses burned, and by Friday you know more about your own content operation than most companies learn in a quarter — which is rather the point of paying senior people to start.

What to Demand From AEM Implementation Partners

Beyond the general partner-selection wisdom, implementation projects deserve implementation-specific screens:

• A phase-one team you've met. Discovery is where fees earn themselves. Ask exactly who runs it and what their last content-model workshop looked like.
• An inherited-estate story. Partners who've rescued implementations know where bodies get buried; partners who've only done greenfield haven't seen their own decisions age. We'd argue rescue experience — of which we have plenty — is the single most valuable credential in this market.
• Author-experience evidence. A demo of an authoring environment they built, judged by whether your least technical editor could use it.
• An integration plan with dates in it. Contracts and test environments in the first month, not "phase two".
• A migration philosophy. If the answer to "how do you migrate content?" doesn't include the words restructure or prune, keep interviewing.
• Named individuals in the contract. The industry's bait-and-switch habit — seniors sell, juniors deliver — dies when CVs are contractual.

Certifications and partner status matter as a floor — Adobe audits Gold partners like us on certified headcount and delivery — but the screens above are where implementation quality actually shows.

The DWAO Implementation Playbook

Since we're asking you to apply hard screens to partners, here's how we answer them ourselves. This is the playbook we run on every AEM implementation, written down the way we'd want a vendor to write it for us.

Content-first discovery. We workshop content models with your editors and watch them work in their current tools. The friction they've stopped noticing becomes requirements. Success criteria get written and signed in week one — the yardstick for every later decision, including ours.

Architecture with a conscience. Cloud Service pipelines from day zero, dispatcher strategy designed rather than defaulted, and a component plan that starts from Core Components with every proposed customization argued in writing against its long-term cost. We say no early and often; it's cheaper than saying sorry later.

Increments, demoed. Working software every two weeks, on the real platform, with your team in the reviews. Steering decks summarize demos — never replace them.

Integration honesty. Third-party contracts drafted in month one, test stubs before dependencies are ready, and the risk register updated weekly with names attached. When something external slips — something external always slips — you hear it from us first, with options.

Authors before launch. Content migration runs with editorial involvement (restructure, prune, improve), and your authors publish production content during soft launch. Go-live isn't called until they can work without us in the room. Documentation lives in your systems, written as we build, because handover documents written in the final week are fiction.

Hypercare, then honesty. A support window sized to launch risk, then a straight conversation about what ongoing support you actually need — managed services if the case is real, a clean handover if it isn't. Implementations that manufacture dependency are the industry's quiet scandal; we'd rather earn the next project.

Teams across our five delivery countries — USA, India, UK, UAE, Thailand — let us shape the model to yours: onshore-led with follow-the-sun build capacity, or fully overlapped with your working day.

The Team Your Implementation Should Come With

Proposals talk about phases; projects are staffed by people. Here's the team shape a serious AEM implementation carries, so you can audit org charts instead of adjectives.

An AEM architect who owns the technical decisions end to end — content models, component strategy, integration patterns, dispatcher design — and who was in the discovery workshops, not parachuted in after. If the architect who designed it won't be around to live with it, design quality becomes someone else's problem by construction.

AEM developers with platform-specific craft: Sling models, Core Components extension patterns, Cloud Service constraints. General Java talent can learn AEM — on someone's project, over months. Certified, current AEM engineers skip that tuition, and ours carry it as a hiring bar.

A front-end engineer who respects the authoring contract. The classic quiet failure: beautiful front-end built as if AEM were a static site generator, leaving editors unable to change anything. Front-end work inside AEM is a discipline of its own — components that render beautifully and author sensibly.

A delivery lead who runs the increments, surfaces risk early and tells you about slips before you discover them. In our model this person carries the integration risk register personally, because integration is where schedules die quietly.

Your people, embedded. An implementation that happens to your team produces a platform your team can't run. Your developers pair on the build; your editors join authoring sessions from mid-project; your platform owner co-writes the runbook. This costs a little velocity in month two and repays it permanently from month six.

Ask every candidate partner for this roster with names. The answer — specific people versus "we'll staff appropriately" — is itself a finding.

After Launch: The First 90 Days Decide the Next Five Years

Implementations get judged at go-live; estates get made in the quarter after. The pattern we've built into our delivery, because the data of experience demands it:

Days 1–30: hypercare with intent. Not just incident response — active watching. Author behavior reveals which templates confuse (fix them now, while budget and attention exist). Performance under real traffic reveals what load tests approximated. Every hypercare finding either gets fixed or gets a written why-not; the punch list that survives hypercare unexamined becomes next year's technical debt.

Days 30–60: the authoring audit. We sit with editors again — the same observation discipline as discovery, now on the real system. Are they publishing at the speed the business case promised? Where do they hesitate? Small template refinements here have outsized returns because habits are still forming; the workarounds authors invent in month two calcify by month six.

Days 60–90: the ownership conversation. With the estate stable and authors fluent, the honest talk: what does this estate need ongoing, and who should provide it? Sometimes the answer is a managed service; sometimes a light support retainer; sometimes your team is genuinely ready and the right move is a clean handover with scheduled health checks. We put the options in writing with our recommendation — and our recommendation is not always the biggest contract, which is precisely why the recommendations get trusted.

That 90-day arc is also your best partner-evaluation question, asked in reverse: "What happens after launch?" Partners with a real answer describe something like the above. Partners without one consider the project finished at the press release — and their estates show it by year two.

Budgeting: What Actually Moves the Number

Implementation cost tracks scope drivers you can estimate before any vendor call:

Licensing sits on top and is negotiated with Adobe — our AEM pricing guidance covers those mechanics separately. For delivery, a scoping conversation produces a genuine range against your drivers; we do that without charge or obligation, because implementations scoped honestly at the start are the ones that end well — and those are the only kind worth our name being attached to.

A Final Word: The Decision Behind the Decision

Choosing among AEM implementation partners is really choosing what kind of estate you'll own in year three: one where editors publish in minutes and upgrades are non-events, or one where a component zoo guards a backlog of regret. The software is the same in both futures. The partner isn't.

Ask the hard questions. Demand the named team. And if you'd like to see how our answers hold up under your scrutiny, we're easy to test — a senior consultant, one business day, and a conversation that's useful whichever way you decide.