When teams use Entity Share to syndicate Drupal content between sites
Teams use Entity Share when several Drupal sites need to share content such as nodes, taxonomy terms and media, but the business needs those sites to stay separate installations with their own codebases, editors and release schedules. Entity Share is a collection of contributed modules that exports content entities from one Drupal instance and imports them into another, so a regional site or a partner site can display material that is authored once elsewhere. The current 8.x-3.13 release supports Drupal ^10.3 or ^11, which means a new build should target one of those versions rather than an older branch. Confirm the exact support statement on the Entity Share project page before you commit to a version, because the requirement is the first thing to check against your core target.
Entity Share is a better fit than a multisite or Domain Access setup when the sites must not share one database or one codebase. Multisite runs several sites from one installation, and Domain Access runs several branded sites on one shared database. Both lock the sites into a common upgrade cycle and a common hosting boundary. Syndication suits organizations where a hub owns authoritative content, a spoke site has its own deployment and security perimeter, and the two must exchange only specific entity types under specific rules. Decide early which entities move, which fields travel, and which content, such as local navigation, forms, user accounts and site configuration, remains local to each site. Those decisions shape the build more than the module installation itself.
The main design work sits in the authentication between sites and in the boundary of what is shared. Confirm how each spoke will authenticate to the hub, what permissions the consuming account holds, and whether that account can read only the entities it needs. Plan for content that references local entities, such as a media item pointing to a file or a term that exists only on one site, because those references must resolve on the receiving side. Ask any implementation partner to document the import rules, the update behavior when the source changes, and the recovery steps if a spoke falls out of sync. Test these paths with real editorial workflows before launch, since a syndication fault usually shows up as a missing image or a stale page rather than an error message.
What Entity Share does on each site
Entity Share splits the work between a site that exposes content and a site that receives it. Each card below describes one part of that split, so you can map which decisions belong to the source site, which belong to the receiving site, and which need agreement between both teams.
Exposing entities for export
On the source site, Entity Share makes content entities available to be read by another Drupal instance. Each exposed entity is a decision about what leaves the site, so treat the export configuration as a data sharing control, not a convenience setting. Check which fields are included, whether unpublished content can be exposed, and who on the source team can change the setup. Confirm the exact configuration screens and options on the Drupal.org project page.
Importing entities on a receiving site
The receiving site pulls content from the source and creates or updates local entities. Plan how repeated imports match existing items, so a re-run updates content instead of creating duplicates. Also decide who owns imported items, since editors on the receiving site may be tempted to change content that the next import will overwrite. Confirm the update and matching behavior for your version on the project page.
Selecting entity types and bundles
Entity Share works at the level of entity types and bundles, such as article content types, tag vocabularies or media types. Narrow selection keeps syndicated data predictable and limits what a receiving site stores. Map each bundle on both sides before the build starts, and note any bundle that exists only on one site. Verify the field mapping rules for your release on the project documentation.
Handling media and referenced entities
Nodes often point to taxonomy terms, media items and other nodes, and those references must resolve on the receiving site. Decide whether referenced entities travel with the content or whether the receiving site must already hold them. Media files raise a separate question about where binaries are stored and whether both sites can reach them. Test a node with images and tagged terms end to end before you commit to a model.
Running imports from the interface and Drush
Imports can be triggered from the Drupal administration interface for manual runs, or from Drush for scripted and scheduled runs. Choose the method that matches how editors and operators will work, and make sure the scheduled path has logging and alerting. Confirm the exact Drush commands and their options for your release on the project page before writing runbooks, rather than copying them from older articles.
Authenticating between sites
The receiving site must authenticate to the source before it can read exposed entities, so credentials and access rights need an owner on each side. Confirm which authentication methods the release supports, how credentials are stored, and how they are rotated when staff change. Keep the source permissions narrow, because an import account with broad read access exposes everything that account can see.
Hub and spoke, peer-to-peer, or one-way feed: choosing the topology
A hub and spoke layout places one Drupal site at the centre as the system that owns shared content. Spokes pull the entities they need from the hub, usually nodes, taxonomy terms and media, and render them under their own branding and navigation. Ownership stays with the hub, so editors on spokes do not change the authoritative copy. This model suits organizations that publish one body of content, such as a product catalog or policy library, to many regional or partner sites.
- Data ownership: The hub owns shared entities. Spokes hold imported copies that are refreshed on each sync.
- Who edits what: Central editors work on the hub. Local teams add only content that stays on their spoke.
- Conflicts and deletions: Because the hub is the single source, conflicts are rare. Confirm how a deletion or unpublish on the hub propagates to spokes and whether spokes can override imported fields.
- Operational load: The hub carries the heaviest load, since it serves every spoke and needs to stay available for pulls. Spokes depend on it for fresh content.
- Authentication: Each spoke needs a credential that the hub accepts for read access. Plan how those credentials are issued, rotated and revoked.
Before committing, confirm which Entity Share modules and release line your sites run, and test how your hub behaves when a spoke requests a large batch of entities.
A one-way feed moves content from a single source site to one or more consumers that never send changes back. It is the simplest topology to reason about because the direction of data is fixed. Consumers can be public-facing sites, a partner portal or an internal reporting site. The source keeps full editorial control, and consumers treat everything they receive as read-only.
- Data ownership: The source owns all syndicated content. Consumers store copies and should not be treated as systems of record.
- Who edits what: Editors work only on the source. Consumers may have local content types for their own pages, but they should not edit synchronized entities.
- Conflicts and deletions: Conflicts cannot arise from consumer edits, but consumers still need a rule for entities removed at the source, such as unpublishing or deleting local copies after a sync.
- Operational load: The source handles export requests and sync scheduling. Consumers carry lighter work, mostly monitoring sync failures and storage growth.
- Access control: Consumers need only read credentials. Keep those credentials separate from any editorial accounts.
Confirm with your editorial team which fields a consumer may override, since any override turns a one-way feed into a partial two-way relationship that needs conflict rules.
Peer exchange means each site both publishes and consumes content from the others, with no single authority. It fits partner networks or affiliated organizations where each site contributes its own material and benefits from the rest. Ownership is split by entity, so every shared item needs a clear origin site. This is the most flexible topology and the one that needs the most governance.
- Data ownership: Each entity has one originating site. The originating site controls its edits, and other sites hold copies.
- Who edits what: Each site's editors manage their own content. Editing a copy from another site is usually blocked or leads to a conflict that someone must resolve.
- Conflicts and deletions: Two sites may both change a shared term or translation. Decide in advance which site wins, whether deletions travel between peers and how a deleted origin affects copies.
- Operational load: Every site runs exports and imports, so monitoring, upgrades and credential management multiply with each peer added.
- Trust model: Each pair of sites needs mutual authentication and agreed content rules, which grows quickly as the network expands.
Ask for a documented map of which site originates each content type before any build begins, and test a deletion and a conflicting edit on a staging copy of each site pair.
Configuration decisions that shape the syndication design
This table compares the configuration choices that set how content moves between Drupal sites with Entity Share, with the option each choice offers and when it fits. Read each row against your own content model, then check the stated settings in your staging sites before you commit to a design. The main takeaway is that pull direction, media handling and translation scope are hard to change after content has already synced, so settle them first.
| Decision | Options in Entity Share | When each option fits |
|---|---|---|
| Entity types in scope | Nodes only, or nodes plus taxonomy terms and media, each enabled as its own exposed entity type | Nodes alone suit a single article feed. Add terms and media only when referenced entities must exist on the receiving site, and verify that each referenced type is exposed on the source. |
| Bundle and field mapping | Map each source bundle and field to a matching bundle and field on the receiving site, or skip fields that have no match | Use one-to-one mapping when both sites share a content model. Where models differ, confirm each mapped field type matches, because mismatched types fail silently or drop values. |
| Pulled versus local fields | Fields that take values from the source, and fields the receiving site owns and edits | Pull editorial content such as body and title. Keep site-specific fields such as local menu placement, promotion flags and page layouts local, and verify that local edits are not overwritten on the next import. |
| Update direction | One-way pull from a hub to spokes, or independent pulls with each site as a source for others | Hub and spoke with one-way pull keeps ownership clear. Two-way or mesh setups need a rule for which site wins on conflicting edits, which the module does not decide for you. |
| Media file transfer versus remote references | Copy files to the receiving site, or keep references that load files from the source site | Copying suits sites that must keep serving assets if the source is offline. Remote references reduce storage but depend on source availability and its access rules. Confirm which option your legal and performance requirements allow. |
| Scheduling of imports | Manual import, scheduled import through cron or Drush, or a separate queue-driven run | Manual runs fit a small, controlled set of content. Scheduled runs suit frequent updates, but confirm cron reliability and check how long imports take on your largest content sets before setting intervals. |
| Translations | Import only the default language, or import all translations exposed by the source | Default-language imports keep scope small. Importing every translation multiplies entities and sync work, so confirm which languages the source exposes and that the receiving site has them enabled. |
| Unpublished content | Import only published entities, or include unpublished entities with their status preserved | Publishing-only imports avoid leaking drafts across sites. If editors need previews on spokes, confirm that access permissions for unpublished content are set on both sides. |
How authentication between sites is set up
Authentication between sites starts with a trust decision: the receiving site must know which sending sites it accepts content from, and each sending site must know which account it is allowed to act as. Entity Share works by one Drupal instance requesting content entities from another over HTTP, so the requesting side needs a credential that the serving side recognizes and that is tied to a specific user account with a defined set of permissions. Treat the sending site as a separate trust boundary. The hub or the source site should expose only the content and fields the syndication is meant to carry, and the receiving site should accept data only from the endpoints you have registered. Confirm for your module version which authentication methods Entity Share supports (for example, a dedicated user with a token, HTTP basic credentials or an OAuth-style client), because the options are not the same across releases. Check the current documentation on the Entity Share project page before you design around any single method.
Apply least privilege to the syndication account. Create a dedicated user that is not an administrator and does not share a login with editors or developers. Grant only the view permissions for the entity types, bundles and fields being exported, and deny create, edit and delete rights on the serving site unless a reverse flow has been designed and approved. Record which account each receiving site uses, what it can read, and who owns the account, so a revoked or compromised credential can be traced and removed without affecting other integrations. Where the receiving side needs to write, keep that account separate from the read-only export account and review its role every time a new content type is added to the feed.
Store every credential outside the Drupal configuration export and out of version control. Keep the values in your secrets manager or in environment-level settings, and make sure the rotation procedure is written down before go-live: who issues the new credential, where it is deployed on each site, how the old one is revoked, and how the change is verified. Because credentials travel in requests, all traffic between sites must use TLS, with certificates managed and renewed by your infrastructure team and plain HTTP refused at the edge. Confirm with your security team how often the credentials must rotate under your own policy, and test a rotation in a non-production pair of sites before relying on the procedure in production.
What should stay local on each site
The most useful decision before building an Entity Share setup is which data each site owns. Syndicated content is easy to move; the harder question is what should never be overwritten by an import. Menus, local navigation, site-specific settings, users and roles, local SEO overrides and locally owned taxonomy usually belong to the receiving site, because each site has its own audience, legal footprint and editorial team. Decide this per entity type and per field, and record it in a field ownership matrix that both teams sign off before any export configuration is written.
The main editorial risk is silent overwrite. When a spoke site re-imports a node, a local correction to the title, summary or meta description can be replaced by the hub's version on the next sync, and editors may not notice until a page reads wrongly in production. Plan for this in the build: decide which fields are pulled and which are read-only on the spoke, whether local-only fields such as a regional call to action or a local canonical URL sit on the same entity or in separate fields that the import does not touch, and who is allowed to change the hub copy. Test a sync with a deliberately edited spoke field to confirm the behavior you expect, because the exact import handling depends on your configuration and the module version you deploy, which you should confirm against the Entity Share documentation for your release.
Users and roles deserve separate treatment. Syndicated content references authors and terms, but account data, permissions and role assignments should remain under each site's own identity policy, and authentication between sites should be designed separately from content flow. Locally owned taxonomy, such as regional categories, needs a decision on whether terms are shared at all, since a shared term that a spoke site renames can change content on every other site. Write down the owner, the sync direction and the conflict rule for each of these items so that the build reflects an agreed model rather than defaults.
Implementation sequence for a syndication build
This sequence moves a syndication design from an agreed content inventory to a monitored production flow, with each step producing a named artifact that the next step depends on. It keeps the source and destination responsibilities clear before any entity is pushed or pulled between sites.
Inventory content and map ownership
List every content type, taxonomy vocabulary and media type that is a candidate for syndication, and record which team owns each one on the source site and on each receiving site. Mark which fields are shared and which stay local, such as menus, local navigation, regional calls to action and editor-only notes. The step closes with a signed content inventory and ownership map, which becomes the reference for every later decision. If the owners cannot agree on a field, that field stays local until they do.
Run the topology and field mapping workshop
Decide the hub and spoke layout, which site is authoritative for each entity type, and how sites reference each other's content. Walk through each shared entity field by field, noting the target field on the receiving site, the value transformation and any reference fields that point at entities that may not exist yet. Confirm the Entity Share version your Drupal core supports by checking the project page, since the module's current release lists its supported Drupal versions. The output is a topology diagram and a field mapping sheet that both teams sign off.
Set up environments and authentication on both sites
Build matching non-production environments for the hub and each spoke, with the same Drupal core, contributed module versions and PHP version. Configure the authentication method the sites will use to talk to each other, and create a dedicated account with the minimum permissions needed for syndication on each side. Store the credentials in your secrets manager rather than in exported configuration. Verify the connection by requesting a single entity from the hub and confirming the response on the spoke. The output is a working test connection and a short document listing accounts, scopes and where secrets live.
Pilot one entity type with a small content set
Choose one entity type, such as taxonomy terms, which usually have fewer dependencies, and syndicate a small, representative set of entries to the spoke. Check that field values, language versions, URL aliases and references land as the mapping sheet specifies, and log every difference. Fix mapping errors in the configuration and repeat the pilot until the results match the sheet. The output is a pilot report with the set of entities tested, the defects found and the fixes applied.
Test imports, updates, deletions and media
Extend testing to nodes and media, covering creation, edits on the source, unpublishing, deletion and re-import after a failed run. Confirm how media files are fetched and stored on the receiving site, and whether derivative images are regenerated locally. Test a deletion on the source to see what happens on the spoke and decide whether the spoke removes, unpublishes or keeps the copy. Run the cron or queue process at realistic intervals on the test environment and watch for duplicate or orphaned entities. The output is a test matrix with pass or fail results and a documented decision for each deletion and media case.
Train editors and write the runbook
Train editors on which fields they can change on each site, how a locally edited copy is treated when the source updates, and how to report a sync that looks wrong. Write a runbook for operations staff covering how to pause syndication, rerun a failed batch, rotate credentials, and check logs on each side. Have the runbook reviewed by the team that will receive the on-call duty. The output is trained editors, a completed runbook and a list of named owners for each sync problem.
Cut over to production and monitor
Schedule the production cutover with a rollback plan that returns the spoke to its previous content state. Enable syndication for each entity type in the order the pilot validated, and compare entity counts and sample records between the hub and each spoke after the first full run. Set up alerts for failed syncs, authentication errors and growth in the number of orphaned entities, and review them during the first weeks of live traffic. The output is a production cutover record, a monitoring dashboard and a scheduled review of sync health.
What drives the effort and cost of a syndication project
This table lists the factors that change how much work an Entity Share project takes, with a way to keep each one under control. Read it as a checklist for the written specification, since the scope you agree on sets the quote. No prices or durations are given here, so ask for both against your own environment.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of sites | Each hub or spoke needs its own configuration, credentials, endpoints and testing, and every pair of sites adds integration paths to verify. | Limit the first release to the sites that need shared content and add others in later phases with the same pattern. |
| Content types and fields to map | Every entity bundle and field needs an explicit mapping decision for what is shared, how references resolve and how values are transformed. | Share a short list of bundles, reuse field names and types across sites, and drop fields that editors do not need on the receiving side. |
| Media volume and file handling | Syndicated media means transferring binaries, managing file paths and checking storage and bandwidth on both ends. | Syndicate metadata and derivatives only where needed, and confirm file size limits and storage plans before testing bulk transfers. |
| Translation complexity | Translated entities, language fallbacks and per-language field mappings multiply the test cases and the mapping rules. | Agree which languages sync and which content stays single-language, and define the fallback behavior before the build starts. |
| Editors who touch shared content | Each editor group needs permissions, review steps and rules for which copies may be edited locally, and these rules are tested with real workflows. | Name the owning site for each content type and limit local edits to fields that are safe to diverge. |
| Custom field types and plugins | Field types outside core need custom normalization or denormalization code, which must be written, reviewed and kept working through upgrades. | Prefer core and well-supported contributed field types, and keep custom code in a small, tested module. |
| Drupal version on each site | Sites on different major versions need compatible Entity Share releases and PHP versions, and a mismatch can block the whole design. The Entity Share 8.x-3.13 release supports Drupal ^10.3 or ^11. | Confirm each site's core and PHP version before design, and plan upgrades on all sites before the syndication design is frozen. |
| Authentication between sites | Each connection needs its own credentials or token setup, rotation rules and access checks, which add configuration and testing work. | Use one agreed authentication pattern across all connections and document how credentials are issued, rotated and revoked. |
Keeping every site on a supported Drupal version
Every site in a syndication exchange has to run a Drupal version that Entity Share supports, so the upgrade plan covers the whole estate, not one site at a time. The Entity Share 8.x-3.13 release supports Drupal ^10.3 or ^11, and Drupal 11 is the current major version. Drupal 10 reaches end of life on December 9, 2026, so any hub or spoke still on Drupal 10 will need a move to Drupal 11 before that date, and Drupal 12 is scheduled for the week of December 7, 2026. Before you commit to a date, confirm the Entity Share version you plan to run against each target Drupal version, because the module's support range is what limits the order of moves.
Plan the upgrades together. A hub that moves to a new core version while its spokes lag can break the JSON that spokes import, and a spoke that moves ahead can push content the hub cannot yet read. Inventory the Drupal core version, the Entity Share version and the PHP version on every site, then set a single target window for the exchange. Drupal 11 requires PHP 8.3 or later, so confirm that every host can run it. Drupal's core release schedule places bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, which gives you a predictable calendar for patch windows. Security releases should not wait for the next quarterly window if they touch core or Entity Share.
Test syndication after every core or module update, not only after major upgrades. Run an export from one spoke, import it to the hub, and check that nodes, taxonomy terms and media arrive with the expected fields, references and file records, then repeat in the other direction. Keep a short set of reference content items for this check so results are comparable between runs. Keep a record of the Drupal and Entity Share versions in use on each site, and treat any site that cannot take the current security release as a risk to escalate, not a site to skip. Ask any partner quoting this work how they will schedule these tests and who signs off each site.
How syndication connects to identity, search and the wider Drupal estate
Entity Share moves content between Drupal sites, but each syndicated site still depends on identity, search, deployment, monitoring and editorial workflow. The cards below cover the decisions that connect those parts, so they can be planned before the hub and spoke design is built.
Editor sign-in across sites
Each Drupal site authenticates its own editors, so decide early whether hub and spoke editors sign in through one identity provider. The OpenID Connect and SAML Authentication modules can each let an external provider authenticate Drupal users. Check how accounts are created on first sign-in, how roles map from the provider, and what happens to a spoke account when a person leaves.
Search indexing of imported content
Imported nodes and terms are stored as local entities on the receiving site, so they must be indexed there to appear in site search. Confirm which search index covers syndicated content types, whether the index is rebuilt after each import, and how deleted or unpublished source items are removed from the index so stale results do not remain.
Composer-based build and release
Entity Share is installed as Composer packages, so every spoke and the hub need the same module versions and a repeatable build. Pin the release line, confirm that the 8.x-3.13 release is compatible with your Drupal core version, and test upgrades on a staging copy of each site before a coordinated release across the estate.
Monitoring of import jobs
Syndication runs as scheduled jobs, and a failed import can leave a spoke quietly out of date. Define what success looks like for each job, who receives alerts, and how a partial failure is retried. Review logs for skipped entities and authentication errors, and confirm that cron or queue processing runs reliably on every site.
Content workflow with moderation
Syndicated content may need review on the receiving site before it goes live, which interacts with the moderation states that editors already use. Decide whether imported items arrive published, unpublished or in a review state, and who may change them locally. Test that local edits to a syndicated item are preserved or overwritten according to a documented rule.
Security updates across the estate
Every connected site receives Drupal core and contributed module security releases on the Wednesday security release windows, so a vulnerability fixed on one site must be applied to all of them. Set a patch routine that covers the hub, each spoke and the Entity Share modules together, and subscribe the team to security advisories for every module in use.
Common questions before hiring a partner for Entity Share
What does an Entity Share project cost and what drives the price?
Cost depends on the written scope: how many sites take part, which entity types move (nodes, taxonomy terms, media), how much field mapping and transformation is needed, and how many environments must be built and tested. A hub and spoke layout with a few content types costs far less to design than a multi-region network with custom field logic and media rules. Ask for a quote that separates the one-time build (discovery, module configuration, custom mapping, testing, cutover) from recurring work such as Drupal core and module updates, monitoring and support. Entity Share itself is GPL-2.0-or-later software, so there is no license fee to budget for the module, though the hosting and staff time around it still cost money.
How long does an Entity Share build take?
Duration is driven by the number of content models that must match across sites, the complexity of the mapping, how many sites need separate authentication setups, and how much of the existing content must be cleaned before it syndicates. Teams that already maintain consistent content types and shared taxonomies move faster than teams that first have to agree on a common model. Ask for a timeline tied to named milestones: discovery of what is shared and what stays local, a proof of concept between two sites, full build, performance and access testing, and a staged rollout. A proposal should state its assumptions so you can see which of them your own data may break.
What must our team provide before a syndication project starts?
The team needs to supply decisions and access more than code. Content owners must agree which content types, taxonomy vocabularies and media types are shared, and which fields are authoritative on the hub and which are local to each spoke. You will need administrative access to every participating site, separate non-production environments that mirror production versions, a named owner for each site who can approve changes, and a list of consumers that will read the syndicated content. Confirm also who holds the decision on what happens when a spoke edits a field that the hub owns, because that choice shapes the whole data model.
Can an internal team build Entity Share without a partner?
Yes, if the team has Drupal developers who understand content entities, configuration management and the Entity Share modules, and if the project is small enough to test thoroughly in-house. Internal teams often struggle with the decisions that are hard to reverse: the shared data model, the authentication between sites, and the rules for what stays local. A partner adds value when the estate has several sites, when there are compliance or access requirements to document, or when the internal team lacks time to run the testing and cutover. Whichever route you choose, ask whether the work will be fixed-scope with written deliverables, and who will maintain the result afterward.
How are Drupal core and Entity Share updates and security fixes handled?
Drupal core bugfix releases come on the first Wednesday of each month, and security releases on the third Wednesday, according to the Drupal core release schedule. Each syndicating site must be updated, and the Entity Share modules must stay compatible with the Drupal version in use, so an update plan should cover every hub and spoke together. Check the Entity Share release notes before each core update, because the 8.x-3.13 release supports Drupal ^10.3 or ^11. Agree on a test environment, a rollback path and who decides when a spoke waits. Ongoing support can be arranged as a retainer, and that cost should appear in the quote as a recurring line.
What happens to imported content if the hub changes or is removed?
It depends on how the syndication was configured, so this should be decided during design rather than after an incident. Content pulled into a spoke is stored in that spoke's database, which means it stays available if the hub is changed, but it may go stale and stop receiving updates. If the hub changes its content model, field names or identifiers, the import mappings on each spoke may fail. Plan for a documented source of truth, a process for deleting or unpublishing content that the hub removes, and regular tests that confirm each spoke still imports correctly after a hub change. Ask any partner to show how they will test this before go-live.
What stays local on each site and why does it matter?
Anything that should differ per site should stay local: menus, site-specific navigation, user accounts, roles and permissions, local comments and any field that a regional team edits independently. Shared content should be limited to entities that genuinely need one authoritative version. Keeping this boundary clear reduces conflicts, simplifies access control and limits what must be tested after each update. It also affects compliance, because personal data copied to several sites increases the places where it must be protected and deleted. Document the boundary in a data map that engineers, editors and security reviewers can all read.
How DeployOpen scopes and delivers Entity Share work
DeployOpen plans and builds Entity Share syndication inside infrastructure you control, starting with a written scope that names every content type, direction of flow and authentication method between sites. Each stage ends with documented deliverables your team can review, test and run after handover.
How we scope
- Engagements are fixed-scope, with the sites, entity types, sync directions and deliverables agreed in writing before work starts.
- We map which nodes, terms and media are shared and which fields, menus and users stay local to each site.
- We confirm your Drupal version and the Entity Share release that supports it, so the plan matches your running platform.
How we build
- We configure hub and spoke exports and imports, then test each entity type with representative content, including media references.
- We set up authentication between sites and verify that credentials, keys and secrets are stored outside the codebase.
- We document field mappings, sync schedules and failure handling so editors and operators can trace where content came from.
How we hand over
- You receive the custom configuration, a written runbook for adding a new spoke and a record of the test results.
- We walk your platform and editorial teams through how syncs run, how to review failed imports and who owns each site.
- Handover covers the environments you operate, with the deployment steps documented for your own release process.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering Drupal core and Entity Share updates.
- We plan upgrades around Drupal's release schedule so that hub and spoke sites move to supported versions together.
- Ask for a quote that lists who maintains the sync jobs, how security updates are applied and what is included in each retainer.
