How a Drupal 7 field collection migration to Paragraphs fits into the upgrade
If your Drupal 7 site stores repeating or nested content in field collections and must move to a supported Drupal version, the field collection to Paragraphs path is one step inside a full migration, not an in-place update. Drupal 6 and 7 sites cannot be updated to Drupal 10 or later. They are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and the themes must be rebuilt. Field collections sit in that content mapping. Field Collection was deprecated in Drupal 8 in favor of Paragraphs, so the target is a new Paragraphs structure on the new site, and the conversion has to be planned as part of the wider project.
Effort follows the number and depth of the nested collections, more than the total volume of content. A single collection holding a few flat fields on one content type is a small mapping exercise. Collections nested inside other collections, shared across several content types, or holding entity references each add mapping rules and test cases. Ask your partner or internal team to inventory every field collection bundle, its parent entities, its nesting depth and the views, exports and templates that read it. That inventory determines how many Paragraphs types you need and how much of the work is mapping rather than rebuilding.
Before the build starts, confirm the conversion module must be installed on the Drupal 7 source first, because the migration depends on it. Then decide which Paragraphs types will replace each collection and whether the new site's content model should change at the same time. Treat any change to the content model as a separate decision from the migration itself, since combining both makes it hard to tell whether a difference in output came from the move or from the redesign. Check the current support status of the Field collection and Paragraphs projects on Drupal.org when you plan, since the project pages carry the authoritative status.
Which field collection structures map cleanly to Paragraphs
This table compares common Drupal 7 field collection patterns with their Paragraphs equivalents and flags where each one maps cleanly. Read the third column as a checklist to work through for each pattern before the conversion run. The main takeaway is that flat, single-owner collections usually move with little redesign, while nested, user-attached and layout-only collections need planning and testing against the conversion module's documentation.
| Field collection structure | Paragraphs equivalent | Fit and what to confirm |
|---|---|---|
| Single-level repeating group on a node | One paragraph type with the same subfields | Usually clean. Confirm each subfield has a Paragraphs-compatible field type. |
| Multi-value field collection with an unlimited count | Paragraphs reference field on the node, unlimited cardinality | Usually clean. Confirm item order and cardinality survive the conversion. |
| Several collection bundles on one entity | Several paragraph types in one reference field | Usually clean. Map each bundle to a named paragraph type and check the mapping. |
| Collection nested inside another collection | Paragraph nested inside a paragraph | Possible but needs testing. Confirm the conversion module handles each nesting level. |
| Collection attached to user accounts | Paragraphs on a user entity through a custom reference | Needs a decision. Confirm whether the conversion module supports user targets. |
| Collection on revisioned content with older revisions | Paragraph revisions tied to the parent node revision | Needs verification. Test that historical revisions keep their paragraphs. |
| Collection used only as a layout container | Layout Builder section or theme component, not a data entity | Usually needs redesign. Move layout out of content data before converting. |
| Deeply nested collections with many levels | Several nested paragraph levels | Usually needs redesign. Consider flattening or splitting into separate content types. |
Why the conversion module must be installed before the migration runs
Drupal.org documents that migrating field collections to Paragraphs from Drupal 7 requires the Field Collection to Paragraphs module to be installed beforehand, so the first decision is sequencing, not configuration. The conversion module is the piece that lets the migration read Field Collection entities on the Drupal 7 source and write them as Paragraphs on the target. If it is added after the migration has already run, the nested content has no mapping to follow and the team ends up rolling back and rerunning. The Field Collection project is marked unsupported on Drupal.org, while Paragraphs is the widely adopted successor, so the conversion path is designed around Paragraphs from the start.
On the Drupal 7 source site, installing the conversion module means preparing the code and the database before any data moves. Confirm with the Drupal.org known upgrade issues page which module versions are documented for your Drupal 7 and Field Collection setup, and record them in the build plan. Keep the source site unchanged while the migration is tested, so the same database snapshot can be reused across test runs. On the target site, Paragraphs must be installed and its paragraph types created before the conversion is mapped, because each Field Collection bundle needs a matching paragraph type to receive its values.
The practical order is: prepare and snapshot the Drupal 7 source, build the target with the Migrate modules and Paragraphs enabled, create one paragraph type per field collection bundle, then run the migration for the parent content that references them. Verify each step before moving on. Ask your implementation partner to show the module list for both sites at each checkpoint, and confirm that the target's Paragraphs configuration matches the mapping document before any content is imported.
Documented import paths for field collection content
Field collection content reaches Paragraphs through a chain of documented pieces: the core upgrade path, a conversion module and the known-issues list. Each covers a different part of the job, so the plan should name which piece handles which content and where the gaps fall.
Core Migrate and Migrate Drupal modules
The core Migrate, Migrate Drupal and Migrate Drupal UI modules carry the Drupal 7 site into a new Drupal site, covering nodes, users, taxonomy, files and most configuration. They do not convert field collection fields into Paragraphs on their own, so the collection data must be handled by a separate step. Confirm which Drupal 7 entities your site uses and whether each one has a supported source plugin for the target version.
Drush-driven migration runs
Drush runs the same migrations from the command line, which suits repeatable test runs against a copy of production. Teams typically script the run, record the output and rerun it after each fix. Drush does not decide how nested collections map to Paragraphs, so that mapping must be reviewed in the migrated output.
Field Collection to Paragraphs conversion module
The Field Collection to Paragraphs module must be installed before the Drupal 7 data is migrated, because the conversion depends on the field collection structure being present on the source. It converts field collection items into Paragraphs items on the target. Check whether it supports your field collection version, your Paragraphs version and any nested collections, and test on a copy of the database first.
Field collection project status
The Field collection project is marked unsupported on Drupal.org, so it will not receive fixes for new issues. Its use on a legacy site is a risk to plan around, not a long-term dependency. Paragraphs is the maintained option on the target, and the migration plan should record which fields depend on the unsupported project.
Known issues when upgrading
The Drupal.org known-issues page lists upgrade problems that have been reported for Drupal 6 and 7 moves, including field-level gaps. Read it against your field inventory before the first run, and record each listed issue as either not applicable, handled by a patch or a module, or accepted with a manual fix. Revisit the page before each rerun, because entries change over time.
Module compatibility with the target
Every module in the chain must support the Drupal version you are moving to, and the versions must match your PHP runtime. Drupal 10 requires PHP 8.1 or later, and Drupal 11 requires PHP 8.3 or later. Confirm each module's supported core versions on its Drupal.org project page before installing, and pin the versions you tested in your build.
Mapping nested collections by source situation
This is the most common case: a field collection attached directly to a node, such as a repeating set of product specs or banner blocks. Each field collection bundle usually becomes one Paragraph type, and each field on the collection becomes a field on that type. Before you build anything, inventory every node bundle that uses a collection field and record the cardinality, because a collection set to unlimited values maps to a Paragraphs reference field that must also allow multiple values.
- Map one bundle to one Paragraph type: Keep the machine names stable where possible so that field-level mappings in the migration stay readable.
- Match cardinality first: Confirm the Drupal 7 collection cardinality and set the Paragraphs reference field to the same limit.
- Preserve field order: Record the delta order of items per node so you can compare it after the run.
- Check empty collections: Decide whether nodes with zero items get an empty reference or none at all.
- Confirm the conversion module path: The Field Collection to Paragraphs module must be installed before the migration runs, as described in the Drupal.org known upgrade issues.
After the run, compare item counts per node against the source for a sample of nodes across every content type, and confirm the order of items on pages where order carries meaning.
Nested collections are the hardest situation, where a field collection contains another field collection. Paragraphs supports nesting, but the parent-child relationship must be designed deliberately, because the source stores each child against a parent item ID that will change during migration. Map the deepest level first, then migrate parents so that their references point at Paragraph entities that already exist.
- Flatten the hierarchy on paper: Draw each level as a Paragraph type and list which reference field connects it to the level above.
- Migrate bottom up: Create the child Paragraphs first, then the parent items that reference them, so that dependencies resolve during the run.
- Plan the reference fields: Each parent type needs a Paragraphs reference field to its child types with the correct allowed types and cardinality.
- Keep ordering at every level: Ordering is stored per level, so sort and check each level separately.
- Test deep trees: Pick the most deeply nested item in the source and verify its full path on the new site.
Verify that every child has exactly one parent, that no orphaned Paragraphs remain after the run, and that the rendered output on sample nodes matches the source.
Field collections are not always attached to nodes. Some sites store collections on user accounts, such as a list of certifications or addresses, or on taxonomy terms, such as a set of attributes per category. Paragraphs is primarily designed for content entities that display through a view mode, so confirm that the target entity type can host a Paragraphs reference field in your version and that the display configuration meets your needs. Where it cannot, the data may need a different target, such as a custom entity or a flattened field.
- Confirm the host entity type: Check that users or terms can carry a Paragraphs reference field on the target site, and confirm this against the module documentation for your versions.
- Decide on privacy handling: User-attached collections often hold personal data, so decide who can see and edit the Paragraphs before migration.
- Map term-level data separately: Term collections are usually loaded in a separate migration after vocabularies, so keep the dependency order explicit.
- Verify display, not just storage: Some views and templates read the old field names, so confirm they still render.
- Review access on the Paragraphs: Paragraph entities inherit access from their host in some configurations, so test with the roles that will use the site.
After the run, compare collection counts for a sample of users and terms, and confirm that the views and templates that expose them still return the same items.
When the source uses content translation or entity translation, field collections can be translated per language, and each translation may hold its own set of items. Paragraphs has its own translation behavior, so the source translation setting determines whether the migrated Paragraphs are shared across languages or duplicated per language. Decide this per field before the run, because changing it later usually means re-migrating the affected content.
- Identify translatable collections: Check which collection fields and item fields are marked translatable in the source.
- Choose shared or per-language items: Decide whether each language gets its own Paragraphs or shares one set, and document the choice per field.
- Keep item counts per language: A translation can have fewer or more items than the source node, so compare each language separately.
- Map language codes explicitly: Confirm that each source language code maps to an enabled language on the target site.
- Check fallback display: Confirm what visitors see when a translation has no items.
For verification, sample nodes in each language and compare item counts, order and text against the source, and confirm the translation status of each Paragraph entity. The multilingual migration topic covers the wider language configuration in more detail.
Sequence for a field collection migration with a parallel run and cutover
This sequence moves field collection content into Paragraphs in a way that can be checked at each stage, so the Drupal 7 site is retired only after the new site has matched it on a pilot copy and during a parallel run. Each phase ends with a written output that the next phase depends on.
Inventory collections, usage and dependencies
Your team and the partner list every field collection bundle, its fields, its parent entities (nodes, users, taxonomy terms or other collections), and which templates, views, exports and feeds read it. Nested collections are recorded with their depth, since each level needs its own Paragraph mapping. The output is a signed-off inventory that shows which collections carry live content and which are empty or unused. Unused collections can often be dropped from scope, but only after the content owners confirm it.
Install the conversion module and build Paragraph types
The Field Collection to Paragraphs module is installed on the Drupal 7 source before any migration run, because the known upgrade issues for this path depend on it being in place. In the target Drupal site, each field collection bundle is rebuilt as a Paragraphs type, with fields, labels and display settings matched to the inventory. Confirm the exact module version and its compatibility with your target Drupal core version against the Drupal.org project page before you begin. The output is a Paragraph type map and a target site that installs cleanly with the conversion module available.
Run a pilot migration on a copy of the database
The Drupal 7 database and file system are copied to a non-production environment, and the migration runs against that copy only. The pilot shows which collections convert, which fail, and how the Paragraph host fields are populated on each content type. Warnings and skipped rows are logged and reviewed by the migration engineer, and the source copy is kept so the run can be repeated from the same state. The output is a pilot log with a list of issues, each marked as fixed, accepted or blocked.
Reconcile nested items and revisions
Nested collection items are compared with their source by parent, delta and field values, and any item that moved to the wrong parent or lost its order is traced to a mapping rule and corrected. Revision handling is checked next: the latest revision, the published revision and any draft or pending revisions must each point to the right Paragraph items. Counts are compared per content type and per collection, and a sample of records is checked by a content owner in the rendered page. The output is a reconciliation report signed off by the business owner and the migration lead.
Operate a parallel run with content checked on both sites
The Drupal 7 site stays live while the new site is refreshed from the source on a schedule agreed in the project plan, and editors check the same pages on both. Differences in rendering, ordering, access and related views are logged against the reconciliation rules, and fixes go back into the migration code or the theme. Editors also test creating and editing content on the new site so the Paragraph forms behave as expected. The output is a parallel run log with every difference classified and a decision on each open item.
Cut over to the new site
The cutover plan sets out the final source refresh, the freeze on content editing on the Drupal 7 site, the DNS or routing change, the cache clearing and the rollback steps. The final migration is rerun from the frozen source, and the same counts and sample checks used in the pilot and parallel run are repeated. Monitoring and error logs are watched during the first business period after the switch. The output is a cutover record showing the checks that passed, who approved the switch, and the rollback point that was kept available.
Decommission the Drupal 7 site
The Drupal 7 site is taken offline only after the business owners accept the new site in writing and the retention rules for the old database, files and backups are confirmed. Read access may be kept for a defined archive period if your records policy requires it. The Drupal 7 code, which no longer receives security support, is removed from the environment so that it cannot be reached by accident. The output is a decommissioning record that lists the retained archives, their location and their owner.
How revisions and unpublished content are checked after conversion
Do both published and latest revisions convert during a field collection to Paragraphs migration?
It depends on how the migration is configured, so confirm it on a test run before you rely on it. Drupal content can have a published revision that visitors see and a newer draft revision that editors are working on, and the two can hold different field values. Check that the converted entities exist for the published revision and for the latest revision, and that each one points to the correct Paragraph items. Ask the team running the migration to show you how each revision was selected and which Drupal 7 revision IDs map to the new ones. Revisions can differ from the live view because a draft may hold a Paragraph that the public page never showed, or a published page may depend on an older revision that the migration did not carry forward.
How should unpublished and draft content be handled after conversion?
Decide the rule before the migration starts, then test it against real examples from your site. Unpublished nodes, drafts and pending revisions often carry field collection items that editors still need, so they should not be dropped silently. Common options are to migrate them as unpublished content, to migrate only the latest revision of each node, or to archive them outside the new site. Verify that every unpublished node keeps its status, author and dates, and that its Paragraph items appear in the edit form in the right order. Confirm with your content owners which categories of draft they need to keep, because the answer changes the number of entities you check.
How do you compare revision history between Drupal 7 and the new site?
Compare a sample of nodes that have several revisions, not just the current version. For each sampled node, list the revision IDs, timestamps and authors in Drupal 7, then check that the same count and order exist on the new site. Compare the field values of each revision, including the nested items inside every Paragraph, because a field collection can hold several levels of data. Keep a short spreadsheet of the results so that a reviewer can sign off each category of content. Ask the team whether revision logs are kept at all, since some migrations preserve only the latest revision and that choice affects what your editors can restore later.
How do you confirm item order and counts for converted Paragraphs?
Count the Paragraph items per node and per field, then compare each count with the source database. Field collection items are stored with a delta, which sets their order, so check that the delta sequence survives the conversion for every nested collection. Use a query against both databases to list the number of items per node, field and revision, and flag any node where the totals differ. Then open a set of pages in the browser and read the rendered order against the Drupal 7 page. Sort problems are easy to miss on short pages, so include the nodes with the largest number of collection items in your sample.
How do you test rollback for a field collection migration?
Test rollback on a copy of the production database, not on the only working site. Run the migration, record the state of the new site, then run the rollback and confirm that the converted Paragraphs and their revisions are removed while the original Drupal 7 data stays untouched. Run the migration a second time after the rollback to check that it produces the same results, since a rollback that leaves orphaned entities will cause duplicates on the next run. Ask the team to document the exact commands they use, and check that the Migrate tools in your environment support rollback for the migrations you have chosen.
Which checks should a content owner sign off before launch?
Ask content owners to review a defined list of pages rather than browse the site at random. The list should include published pages with nested collections, pages with pending drafts, nodes with many revisions and any page that embeds a Paragraph in a view or a menu. For each page, the owner should confirm that the visible content, the edit form and the revision history match what they expect. Record each sign-off with the date and the revision ID tested. Confirm with your project team how many pages the sample covers and who has the authority to accept gaps, because that decision sets the risk you carry into launch.
Can our own team run these checks, or do we need a partner?
Your team can run these checks if it has access to both databases, a staging copy of the site and people who know the content well. The work is mostly query comparison, sampling and sign-off, and it needs a clear record of what was checked. A partner is useful when the number of nested collections or revision types is large, or when the team does not have the Drupal 7 knowledge to read the source data. DeployOpen plans and documents these checks as part of a fixed-scope engagement, and the written scope states which checks, samples and deliverables are included before work starts. Ask any provider to list the checks they will run and the evidence they will hand over.
What goes wrong in field collection migrations and how to prevent it
Field collection migrations usually fail in the details: nested items that disappear, references that point at the wrong Paragraph, and revisions that do not match what editors saw. The cards below cover the risks that recur on Drupal 7 sites and the checks that catch them before cutover.
Silent loss of nested items
Nested field collection items can be dropped when the source query only reads the parent node revision or when a multi-value field has a cardinality limit on the target. Compare item counts per parent node between the Drupal 7 database and the new site for every collection field. Run the migration on a copy of production and sample nodes that hold the largest number of items, since those are where gaps show up first.
Broken references between Paragraph types
A collection that holds another collection, or a Paragraph that points at a node, needs its parent and child references rebuilt in the right order. If child Paragraphs are created after their parents are saved, the reference fields end up empty. Map each nested level explicitly, migrate the innermost types first, and confirm that every parent-child link resolves on a sample of pages.
Revision mismatches
Field collection items are versioned with their host entity, while Paragraphs has its own revision handling, so a published node can show a different item set than the latest draft. Decide which revision the migration carries forward and whether older revisions are needed at all. Check that the live page and the editor's edit form show the same items after the first full run.
Contributed module gaps
The Field collection project is marked unsupported on Drupal.org, so any contributed module that extends collection behavior may have no Drupal 10 or Drupal 11 release. Inventory every module that touches the collection fields, confirm its current compatibility, and decide early whether to replace it. Ask your partner to document each gap in writing before the build begins.
Theme and template rebuilds
Drupal 7 themes cannot be migrated, so every template that printed a field collection item must be rewritten against Paragraphs fields. Field-by-field output that worked in a Drupal 7 node.tpl.php override will not match the new markup without changes. Plan the template rewrite as its own work item and compare rendered pages against the old site for layout and accessibility regressions.
Editor workflow changes
Editors who added collection items inline on a Drupal 7 form will meet a different widget, drag handles and modal dialogs in Paragraphs. Their habits affect how content is structured after launch, so a change in widget behavior can produce inconsistent pages. Run a short usability session with real editors on migrated content, document the new steps, and confirm permissions for who may create or delete each Paragraph type.
What drives the cost and duration of the conversion
This table lists the factors that change how much work a field collection to Paragraphs conversion takes, who carries each cost and whether the effort is paid once or recurs. Use it to see which answers to request in a written quote, because the largest drivers are usually the ones an initial inventory reveals.
| Driver | Why it changes effort | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Number of field collections | Each collection type needs a mapping to a Paragraphs type, field-by-field checks and sample content review. | One-time | A per-collection inventory with the target Paragraphs type named for each. |
| Nesting depth | Collections inside collections need ordered conversion and more verification passes, since a parent may depend on a child existing first. | One-time | A stated nesting depth and the conversion order for each level. |
| Volume of revisions | Revision history affects how many entity revisions must convert correctly and how long migration runs take on the production dataset. | One-time | Revision counts per content type and whether historical revisions are kept or only current ones. |
| Translations | Each translated field value and each language version of a nested item must be mapped and checked separately. | One-time | Languages in scope and whether translated Paragraphs are in the test plan. |
| Custom code that reads collection fields | Theme preprocessing, custom modules, Views and exports that call collection APIs or field names must be found and rewritten to read Paragraphs. | One-time, with ongoing maintenance of the rewritten code | A list of custom code touching field_collection data and the rewrite approach for each item. |
| Number of templates to rebuild | Node, paragraph and field display templates that rendered collections must be rebuilt because theme code does not carry over. | One-time | Count of templates and view modes affected, with owners for sign-off. |
| Parallel-run checks | Side-by-side comparison of old and new pages, and of field values after each migration run, determines how many test cycles are needed. | One-time, with reruns after each content freeze | The number of parallel-run cycles, the comparison method and who approves the result. |
| Post-launch fixes and module updates | Paragraphs and its dependencies are contributed projects that receive updates, and content editors may find edge cases after launch. | Recurring | Support hours or retainer terms for fixes and updates after cutover. |
Questions teams ask before migrating field collections
How much effort does a field collection to Paragraphs migration take?
Effort depends mostly on how many field collections the site uses, how deeply they nest, and how much of the content depends on them. A site with a few flat collections on one content type is a small job. A site with collections inside collections, used across many content types and carrying years of revisions, needs far more mapping, test cycles and content checks. No public effort figure applies to every site, so ask any partner to base the estimate on an inventory of your collections, their nesting depth, the number of entities that use them and the revision history you need to keep. Also confirm whether the estimate covers the rebuilt display settings and theme templates or only the data move.
How long does a Drupal 7 field collection migration run?
Duration is driven by inventory size, the number of nested levels, how many custom modules or templates reference collection fields, and how many review rounds your content owners need. The migration itself is usually the shortest step. Most of the calendar time goes to building the mapping, running test imports on a copy of production and checking rendered pages. Ask for a schedule that separates inventory, mapping, test runs, content sign-off and cutover, and confirm which of those steps depends on your staff's availability. Ask also how long the Drupal 7 site must stay live during the work.
Can our in-house team migrate field collections to Paragraphs?
A team with solid Drupal 7 and Drupal 10 or 11 experience can do the work, provided it has time to learn the migration path and test it properly. The key facts to check are whether your developers have built custom migrations with the core Migrate API, whether anyone has handled nested entity data, and whether they can run imports repeatedly against a production copy. Field Collection is deprecated in Drupal 8 in favor of Paragraphs, and the Field collection project is marked unsupported on Drupal.org, so your team should expect little community support for edge cases. Many teams split the work: internal staff own content sign-off and the partner owns the mapping and migration code.
Is Paragraphs the right target for Drupal 7 field collections?
For most Drupal 7 sites that use field collections, Paragraphs is the path that current Drupal supports. The Field collection project is marked unsupported on Drupal.org, while the Paragraphs project reports about 276,744 sites, which indicates how widely it is used. Paragraphs is a good fit when editors need reusable, nested content blocks with their own fields. It can be a poor fit if your collections are simple repeating values that a multi-value field or a custom entity would handle more cleanly. Compare each collection's role before committing, and confirm that the Paragraphs features you need, such as nesting limits, layout use and translation, work with your planned Drupal version.
What must our team provide before a migration starts?
The team should provide access to a recent copy of the Drupal 7 database and files, the list of content types and fields that use collections, and the custom code that reads or writes them. It should also provide the templates, views and exports that display collection data, plus named content owners who can approve samples. Staging environments with PHP and database versions that match the target are needed for test runs. Ask the partner to confirm this list in writing as part of the scope, so gaps show up before the schedule is agreed rather than during testing.
What does a field collection migration check that a data import does not?
A successful import only shows that rows were created. It does not show that nested content renders correctly, that revisions point to the right paragraph versions, or that editors can still edit what they used to edit. Checks should cover parent and child relationships at every nesting level, the revision history you chose to keep, translated values if the site is multilingual, and the output of each display mode. Compare sample pages between the old and new sites and ask for a written list of what was checked and what was accepted as a known difference.
Where does DeployOpen fit in a field collection migration?
DeployOpen plans, builds and tests the migration on infrastructure you control, which may include your cloud accounts, data centers or private networks. Most engagements are fixed-scope, with the inventory, deliverables and timeline agreed in writing before work starts. The scope can cover the inventory, the Paragraphs mapping, custom migration code, test runs, documentation and support after cutover. Ongoing support and upgrades can be arranged as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
Where to confirm module and version details
Module compatibility and version support for this migration must be confirmed on Drupal.org at the time you plan, not taken from this page or from a previous project. Start with the known issues when upgrading from Drupal 6 or 7, which records the problems teams have hit when moving Drupal 7 content into a newer site. Read it against your own site's module list, and note any issue that touches field collections, nested entities or revisions, since those are the areas this migration depends on most.
Next, open the project pages for Field collection and Paragraphs and compare what each says about its status. The Field collection project is marked unsupported on Drupal.org, so the conversion path depends on a module that no longer receives active maintenance, while Paragraphs is the target you will be building on for years. Check the supported Drupal core versions, the release you intend to install, and the conversion module's stated requirements, including the Drupal core version it expects. Record the exact release numbers you tested against, because a conversion module that works on one Paragraphs release may behave differently on the next.
Finally, read the Drupal.org documentation on upgrading from Drupal 6 or 7 to Drupal 8 and newer to confirm the migration sequence, including which modules must be installed on the Drupal 7 source and on the new site before the migration runs. Save the dated results of these checks in your project plan and repeat them before go-live, because Drupal core and contributed releases change during a long migration. Any gap you find here should be resolved in writing with your implementation partner before the build starts.
How DeployOpen scopes and delivers a Drupal 7 field collection migration
DeployOpen plans and delivers Drupal 7 field collection to Paragraphs migrations as fixed-scope engagements, with the scope agreed in writing before work starts. We work inside your own infrastructure, from the module installation and nested-collection mapping through revision checks, testing and handover to your team.
How we scope
- Inventory every field collection, its nesting depth, and the content types and revisions that reference it.
- Confirm the target Drupal version and the Paragraphs release that the new site will run.
- Write the scope in advance, listing deliverables, environments, acceptance tests and the exact collections in or out of the migration.
How we build
- Install the conversion module on a staging copy of the Drupal 7 site before any mapping work begins.
- Map each parent and nested collection to a Paragraphs type, documenting field-by-field mappings and any content that needs manual rework.
- Run repeated migration rehearsals on staging and compare revision counts, published states and nested item order against the source.
How we hand over
- Deliver the mapping document, migration scripts, and a log of known exceptions that your editors and developers can review.
- Walk your team through the revision checks and the acceptance results so they can repeat the verification themselves.
- Record the rollback steps and the cutover sequence so the production run can be repeated if a later check fails.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the migration is complete.
- Ask any provider to confirm which Paragraphs and Drupal core versions they will support after launch.
- Agree in the quote who owns post-launch fixes for editor-facing Paragraphs layouts and who handles later Drupal upgrades.
