Adobe Experience Manager Partners

Why the information architecture outlives the build

The content model is the set of decisions about what a piece of content actually is in your repository: whether a product fact lives inside a page or as a content fragment referenced from twelve pages, whether a biography is a page or a reusable structured record, whether a campaign landing page is a template or a one-off. A content fragment in AEM is a structured, channel-independent piece of content with named fields, which can be rendered on a page, served over an API, or syndicated into an app. Getting these boundaries right is what lets you change a legal disclaimer once instead of eighty times.

This matters because the model is the part of an AEM estate that is hardest to change afterwards. Templates can be rebuilt, styling can be replaced, even the front end can be swapped out. But once several thousand pages have been authored against a particular structure, restructuring means a content migration inside your own platform, plus rework to every component that reads those fields. Teams that skip modeling and go straight to visual design usually discover this in year two, when a second market or a mobile app needs the same content in a different shape and there is no clean way to get it.

Questions the model has to answer before anyone writes code

• Where does each fact live once — for every repeated element on the site, name the single place it is authored and the mechanism by which the other places get it.
• What is a page and what is a record — people, products, locations, events and articles are often better as content fragments surfaced by a list component than as hand-built pages.
• How deep does the page tree go — the repository path structure drives permissions, rollout inheritance and search scoping, and it is painful to re-parent later.
• What needs to leave the page — anything a mobile app, an in-store screen or a partner feed will consume should be structured and API-addressable from day one, not scraped out of HTML later.
• Which fields are mandatory — validation rules in the model are how you stop the site filling up with half-authored content that renders badly.

The custom-component ratio is your cost curve and your upgrade curve

Adobe ships a library called Core Components: maintained, accessible, tested building blocks for text, images, carousels, navigation, forms, embeds and more. Every component you build yourself instead is code you now own forever. The ratio between the two is the single most useful number to establish early, because AEM cost is engineering-hour-dense, which means the count of bespoke components moves the total far more than any commercial negotiation will.

The ratio also decides how upgrades feel. Core Components are updated by Adobe and follow a versioning scheme designed so that your content keeps working when the component evolves. Custom components are maintained by whoever wrote them, and every platform change is a test-and-fix exercise across all of them. A site with fifteen custom components has a manageable regression surface. A site with a hundred and forty, many of them near-duplicates created because a designer wanted a slightly different card, has an upgrade problem that never goes away and a component picker no author can navigate.

The productive middle ground is to extend rather than replace. Core Components are designed to be styled and reconfigured through their dialogs and the style system, so a distinctive brand look rarely requires bespoke code. The habit worth establishing early is that a new component needs a stated reason beyond a designer wanting a variation, and that the reason is recorded. That single piece of discipline is what keeps a library at twenty items rather than a hundred, and it is applied during design reviews, not during development, because by the time a component is in a sprint the argument has already been lost.

Where bespoke components are genuinely justified

• Interactions with real logic — configurators, calculators, availability checkers and anything that calls a back-end service while the page is open.
• Domain-specific content displays — a fund performance table or a drug interaction panel has rules no generic component encodes.
• Integrations that render — components that pull live data from a PIM, a booking engine or a stock system and need caching behavior of their own.
• Compliance-driven output — markup that must satisfy a specific regulatory or accessibility requirement that the shipped component does not meet.
• Not for styling differences — a card with a different corner radius, image ratio or text alignment is a style variant, not a component.

The authoring experience your marketing team inherits

Whatever gets built is what your content team uses every day for the next five years, and the quality of that experience is set by choices that are invisible in a design review. Dialog design, sensible field labels, in-context help text, pre-configured template policies that limit which components are allowed in which container, and a component list short enough to scan all determine whether authoring a campaign page takes twenty minutes or half a day.

The practical test is to have two people from the content team build a real page in staging before sign-off, without a developer beside them. If they cannot work out which of four similar components to use, or they hit fields whose purpose is unclear, that is a build issue rather than a training issue. Editable templates and policies are the mechanism for fixing it, because they let you constrain structure centrally so authors get a small set of safe choices rather than a blank canvas. Doing this before launch costs a day; doing it afterwards means changing templates that live content already depends on.

Cloud Manager, environments and the continuous-upgrade constraint

AEM as a Cloud Service changes the deployment relationship substantially compared with the older Managed Services model. Adobe updates the platform continuously, and your code has to keep passing through Cloud Manager, which is the deployment tool that runs build, code quality scanning, security checks, functional tests and performance tests before anything reaches production. You cannot hot-fix a running instance, you cannot install arbitrary packages on the server, and any customisation that depended on modifying the platform itself is no longer available to you.

That constraint is a benefit if the build respects it and an expensive surprise if it does not. Code that assumes a writable filesystem, long-running scheduled jobs on a single node, or direct access to the repository from outside will fail the quality gates or behave unpredictably when instances are replaced. Environment strategy matters for the same reason: development, staging and production behave differently in caching and scale, so performance problems found only in production usually trace back to a staging environment that was never configured to resemble it.

Dispatcher and caching decisions that bite later

• What is cacheable at all — pages with per-visitor content cannot be cached whole, so decide early whether personalization happens client-side over a cached shell or server-side on an uncached page.
• How invalidation works — publishing a content fragment used by two hundred pages must flush all of them, and the rule that makes that happen is configuration you have to write.
• Query strings and variants — tracking parameters can fragment the cache into thousands of near-identical entries unless they are explicitly ignored.
• Time to live versus flush on publish — editorial sites usually want flush on publish, high-traffic campaign pages often want a short time to live as a safety net.
• What the dispatcher blocks — its filter rules are also a security control over which repository paths and selectors the internet can reach, and a permissive rule set is a real exposure.

Migration is a keep, kill or rewrite audit, not a bulk move

Most organizations moving to AEM have far more pages than they need. Legacy sites accumulate duplicate product descriptions, expired campaigns, PDFs nobody has opened in three years and pages that exist only because a team wanted a link in the navigation. Automating a wholesale transfer of that into a new platform means paying to migrate content, paying to re-template it, and then paying again when authors cannot find anything because the tree is full of noise.

The useful exercise is to pull traffic, conversion and last-updated data for every URL and sort the inventory into three buckets. Keep means the content moves largely as-is and can often be scripted. Rewrite means the topic still matters but the content does not survive contact with the new model and needs editorial work. Kill means it is redirected and deleted. That audit typically removes between a third and two thirds of an inventory, and it converts an unpredictable migration into a piece of work you can actually estimate, because the scripted keeps and the manual rewrites have completely different unit costs.

Plan the redirect map as part of that same audit rather than as a launch-week task. Every killed URL needs a destination that genuinely answers the same question, not a blanket redirect to the homepage, and every kept URL needs a decision about whether its address changes at all. Assets are a parallel exercise: PDFs and images carry their own inbound links and their own accumulated clutter, and they need the same three buckets applied. This is the part of an AEM migration most likely to cause a visible commercial problem, because search traffic to a large site does not recover quickly from a broken redirect layer.

Multi-site and multi-language rollout with MSM and live copies

AEM's Multi Site Manager exists to let a master version of a site cascade into variants: other countries, other brands, other languages. A live copy is a child site linked to that master, with inheritance rules that control whether each page, component or field follows the master or has been deliberately broken off and localised. Used well, it means a global product update is authored once and rolled out to thirty markets. Used carelessly, it produces a structure where local teams break inheritance on almost everything to get the page they want, and you end up maintaining thirty independent sites with extra machinery on top.

The design question is what is genuinely global. Usually the page structure, the component composition and the regulated content are global, while imagery, offers, pricing and tone are local. Write that down as a policy before configuring rollout, because inheritance is expressed in configuration and changing your mind later means re-establishing links across live sites. Translation workflow is a separate decision again: AEM can push content to a translation vendor and bring it back automatically, and whether you use human, machine or hybrid translation per market changes both cost and the review process markets have to staff.

Programs rarely stop at one product. Buyers hiring for Adobe Experience Manager often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Campaign partners , or review the whole Adobe landscape before committing.