Drupal Media Library and Entity Browser for asset management

Each media type, such as image, document, video or remote video, adds its own fields, form display, view mode, and often its own validation and storage rules, so effort grows with the count of types rather than with the number of files. Keep the list short and justify each type by a distinct editorial need. Ask the partner to list every media type, its fields, its allowed file extensions and size limits in the written scope, and which types need custom display templates on the front end. Each extra type should appear as a line item so you can see what it adds.

Large libraries and mixed formats add work in three places: the migration run time, the number of edge cases (corrupt files, unusual codecs, duplicate names), and the checks needed to confirm that every asset arrived intact. Reduce this by inventorying the library first, deleting obsolete files, agreeing which formats are in scope, and deciding whether old renditions are kept. Ask for a written inventory summary, a sample migration of representative files, and an explicit statement of what happens to files that fail validation.

Every custom field is a schema change, a form change, a display choice and a migration mapping, and rights fields often need validation and reporting logic. Keep required fields to what editors and search truly depend on, such as alt text for images, credit line, usage rights type and expiry date. Ask the partner to show a field list with the owner of each field, the source of its values, and whether the field must be populated during migration or can stay blank.

A custom selection workflow costs more than the stock Media Library because it adds configured widgets, selection rules, and sometimes custom code to match how editors pick assets in a specific form. Limit it to the places where editors truly need a different flow, and reuse one browser configuration across content types where possible. Before you ask for a quote, write down each selection screen, the filters it needs and who uses it. Ask the partner to separate configuration work from custom module work in the estimate.

Migration covers exporting files and their metadata from the old system, mapping them to Drupal media entities, copying binaries into the target file storage, rewriting references in content, and verifying results. Costs rise when the legacy system has no export tool, when links are embedded in body text, or when file paths are inconsistent. Ask for a mapping document, a dry run on a copy of production data, and a reconciliation report that counts source assets against imported media and lists exceptions.

Build work is one-time: content types, media configuration, Entity Browser setup, migration scripts and editor training. Recurring costs include file storage growth, backups of the file system and database, monitoring disk use, applying Drupal core and contributed module updates, and periodic clean-up of unused media. Storage prices depend on your cloud or data center contracts, so confirm them with your infrastructure team. Ask the quote to show a separate recurring cost estimate and the assumptions behind it.

A useful quote lists scope in terms of media types, fields, selection workflows, migration sources and volumes, editor training sessions and acceptance criteria. It should name deliverables, what the client provides (storage, credentials, sample files, rights decisions) and what is excluded, such as a separate DAM. Ask whether the price is fixed for the stated scope, how changes are priced, what support is included after launch, and whether the Drupal module versions used are current at the time of delivery. Compare quotes on the same scope list, not on headline totals.

For many sites, yes. Drupal core ships Media and Media Library, which cover media types, file and image fields, a browsable library for editors and reuse of an asset across several content items. Teams usually need more when they want custom selection flows inside a content form, multiple asset sources, richer metadata rules or review steps before an asset goes live. Entity Browser, covered on this page, is the usual addition for those selection workflows. Confirm the gaps by testing your real editor tasks against a configured core setup before deciding.

The main drivers are the number of media types, the volume and state of existing assets, the number of custom selection workflows, metadata and rights rules, integrations with an external asset source, and how many editor roles need different views. Each adds design, configuration, custom code and testing. Drupal itself has no license fee: Drupal and the contributed files hosted on Drupal.org that derive from it are licensed under GPL-2.0-or-later, so your recurring cost is hosting, maintenance and support work rather than software licenses. Ask any quote to separate one-time build work from recurring upkeep.

The duration is set by the written scope, not by a standard figure. Timing depends on the asset inventory, how many workflows need custom work, how fast your rights and metadata decisions are made, and how many review rounds editors need. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote is where the duration is confirmed. Ask for the phases, the dependencies on your team and the points where editor feedback is required.

Three inputs carry most of the schedule risk. First, an asset inventory: the file types, volumes, current storage locations and any duplicates or orphaned files. Second, written rights rules: who may upload, reuse and publish each asset class, licence expiry handling and any usage limits. Third, editor availability for workflow reviews and acceptance testing. Missing any of these usually shows up later as rework on field configuration or permissions, so ask the partner to list them in the scope before work begins.

Yes, if your team has Drupal experience and time for configuration, custom module code and testing. Core Media and Media Library are configured through the admin interface and do not require custom code for basic use. Entity Browser and custom selection flows do require developers who can work with Drupal's entity and form APIs and keep custom code upgradeable. Consider whether your team can also own the testing, the upgrade path and the editor support after launch. A partner is most useful when the scope needs more than configuration and the timeline is fixed.

Plan for the version you will run during the build and for the next upgrade. According to the Drupal core release schedule, Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. Entity Browser's 8.x-2.17 release supports Drupal ^10.3, ^11 and ^12. Ask for custom media code to be kept small and tested so the upgrade does not reopen the whole asset model.

Often not at the start. A separate DAM is justified when assets need to be shared across several systems outside Drupal, when you need advanced rights workflows, large-scale transcoding, or when a non-Drupal team is the main owner of assets. If the assets are mainly used on Drupal pages, the core Media Library with well-designed media types may be enough. Confirm the integration needs, the rights model and who maintains the DAM before choosing, because connecting two systems adds ongoing sync work.

Media access should follow the same permission model as the content that uses it. Define who can upload, view, edit and delete each media type, and test that private files are not exposed through public URLs. Confirm file type restrictions, size limits and malware scanning with your security team. Rights rules and licence metadata should be part of the design, not an afterthought. Security testing of the upload paths can be included in scope if your team requires it.