Why Drupal 7 Views need a rebuild plan of their own
If your Drupal 7 site drives listings, blocks, feeds and exports from Views, those Views will not arrive on the new site with the content. Views are not migrated from Drupal 6 or 7 and must be created manually on the destination site. Contributed Views migration modules exist, but they make only a best-effort attempt, so a View that appears to come across may still differ in filters, contextual arguments, relationships, sorting or display settings. Treat every View as work to be verified and, where needed, rebuilt, not as content that will simply reappear after the migration runs.
The effort depends on two numbers: how many Views the site has, and how many other parts of the site depend on them. A single homepage listing that feeds one block is a small task. A set of exports consumed by a finance team, a feed read by an external partner and a search page that reuses the same Views for several content types is a much larger one, because each dependency has to be found, rebuilt and tested against the same output. Ask your current team or agency to list each View with its path, display types (page, block, feed, attachment, export), the content types and fields it uses, and who relies on its output. That list, not a guess from the site menu, is what should drive the estimate and the schedule.
Build the inventory before you commit to a fixed scope. Export the Drupal 7 configuration so the Views definitions can be read outside the admin interface, and check whether any Views are overridden in code or defined by modules that will not exist on the new site. Confirm with your Drupal developers which Views are required on launch day and which can wait, and record the expected output of each one, such as row counts or the columns of a CSV export. Those expected outputs become the acceptance tests for the rebuilt Views during migration rehearsal. Drupal.org's known upgrade issues for Drupal 6 or 7 is a useful reference when you review what the migration tools can and cannot carry over.
What maps from Drupal 7 Views and what needs manual rebuilding
This table compares each part of a Drupal 7 View with its counterpart on the new site and notes whether it moves through the Migrate API or must be rebuilt. Read it as a checklist: the content underneath usually migrates, while the View configuration, its placement and any theme-dependent markup need planning and checking by hand.
| Drupal 7 View element | Drupal equivalent on the new site | Migration note |
|---|---|---|
| Content types and fields | Content types, fields and entity references | Migrated as content and configuration through the Migrate API; verify field types and required settings after the run. |
| Taxonomy listings | Taxonomy term views built in Views | Terms migrate as data, but the listing View itself must be recreated and its filters checked. |
| Pager and sort settings | Views pager and sort handlers | Not carried over reliably; set page size and default sort again and compare results with the old page. |
| Page and block displays | Page displays and Block placements | Rebuilt by hand; confirm paths, menu links and which region each block lands in on the new theme. |
| Feed and export displays | REST, feed or export views configured on the new site | Recreate the output format and field order; test downstream consumers against the new output. |
| Access rules and role filters | Role and permission settings plus View access configuration | Verify each access rule against the new role model before launch so restricted content stays restricted. |
| Exposed filters | Exposed filter handlers and their identifiers | Recreate filter identifiers and defaults; bookmarked or linked URLs with old parameters may break. |
| Theme-dependent markup | Templates and the new front-end theme | Themes cannot be migrated, so template output and CSS classes must be rebuilt and visually checked. |
How to inventory every View before scoping the rebuild
This sequence turns the Drupal 7 Views on your site into a written inventory that shows which listings, pages, feeds and exports must be rebuilt, who depends on each one, and how much work the rebuild will need. The inventory is the input to a fixed-scope quote.
Export the full list of Views
Start from the Views administration screen on the Drupal 7 site and list every View, including disabled ones, default views that were never overridden and Views created by modules that are no longer enabled. Export each View's configuration to a file (for example, with the Views UI export or Drush) so the definitions can be read outside the live site. Done means every View has one row in a spreadsheet and one exported definition on file, with the count checked against the admin screen.
Record the technical definition of each View
For each View, record the base table (node, user, taxonomy term, commerce entity or other), every display (page, block, feed, attachment, embed), the filters, sorts, contextual arguments, relationships, and the access settings for each display. Note where the View is placed, including menu paths, blocks and regions, and any theme overrides or template files. A developer usually does this with the exports open, and a Drupal 7 developer familiar with Views is better placed for it than a generalist. Done means each row lists its base table, displays and placements.
Find Views that fan out or depend on custom code
Flag Views that use custom handlers, PHP snippets, field collections, entity references, or relationships to fields provided by contributed modules that may have no Drupal 10 or 11 equivalent. These Views carry the highest rebuild effort because the logic may need to move into a custom module, a Paragraphs-based layout or a new query. Also flag Views that other Views or code call by name, since renaming one will break its dependents. Done means every View is marked standard, contributed-dependent or custom-code-dependent.
Tag each View by its role
Assign one primary tag to each View: page, block, feed, export, or internal helper (used only by other Views, forms or code). Where a View serves more than one role, record the primary role and list the others. This tag tells the team which Views the editors see, which the public uses, and which can be retired after confirming nothing depends on them. Done means every row carries exactly one primary tag and any secondary roles are noted.
Name an owner and consumer for every feed and export
For each feed and export, identify the consumer outside the site, such as a spreadsheet used by finance, a CRM import, a search index, a newsletter provider, a partner integration or a regulator's download. Name an internal owner for each consumer and the person who can confirm the output still matters. Then run a consumer test: ask the owner to describe the fields, format, frequency and what breaks if the URL or file changes. Done means each external feed has an owner, a consumer, and a recorded yes or no from the owner on whether it must survive the migration.
Check access and usage on the live site
Compare the inventory with the site's access logs, analytics and search data where they exist to see which pages and feeds are used. Confirm which Views are reachable by anonymous users and which are limited to roles, because access rules are a common source of surprises after a rebuild. Ask editors which listings they rely on daily. Done means each View has a usage note (used, rarely used, or unknown) and access rules are confirmed against a test account for each role.
Mark the Views to rebuild, replace or retire
Decide for each View whether it will be rebuilt as is, replaced with a simpler listing, merged with another, or retired. Record the decision with the owner's sign-off. Views that a migration module converts on a best-effort basis still need the same check, so do not treat a converted View as done until its output is compared with the original. Done means every row has a decision and a sign-off or a documented open question.
Turn the inventory into a fixed-scope quote
Group the approved Views into rebuild units with the complexity drivers noted (custom code, number of displays, external consumers, access rules). Share the grouped inventory with DeployOpen so the written scope lists which Views are in, which are out, and which need a decision before work starts. Ask the quote to state what is included for each feed consumer test and what happens if a consumer reports a missing field after launch. Done means a written scope references the inventory by View name and the open decisions are listed.
Rebuild options by View type
Simple listings show one content type or a small set of types, filtered by status and sorted by date or title, with a pager or a block on a page. On current Drupal these are usually rebuilt as a View with the same content type, filters and sort, and most of the work is confirming the query matches the old one rather than designing new behavior. Plan to recreate the display, fields, pager and any contextual filters by hand, since Views configuration does not migrate from Drupal 7.
- Filters and sort: Recreate each filter, including published status and language, and the sort order with its tie-breakers.
- Display mode: Match the fields, formatter and pager size, and decide whether the page or block is served by the same path.
- Contextual arguments: Map any URL or taxonomy arguments to the new route or term reference.
- Access: Confirm that unpublished or restricted nodes are hidden for anonymous and role-based users.
- Caching: Check cache tags so new content appears on the listing without a manual cache clear.
Before cutover, compare the result count and the first and last items in each listing on both sites, using the same account and the same content.
Complex Views join several entities, such as content linked to taxonomy terms, user profiles, field collections or referenced nodes, and often expose filters to visitors. On current Drupal they are rebuilt with relationships, exposed filters and sometimes a custom query plugin, and the old join logic must be translated into the new entity relationships rather than copied. Treat these as the highest-risk Views because a small join change can silently drop or duplicate rows.
- Relationships: Rebuild each join with the matching entity reference, and check whether the old view used required or optional relationships.
- Exposed filters: Confirm that each exposed filter, its operator and its default value behave as before, including empty-value handling.
- Duplicates: Check for repeated rows caused by multi-value fields, and set distinct or aggregation only after confirming the cause.
- Field migration: Verify that any Paragraphs or Media fields used in the join were converted first, because the Views depend on the new field structure.
- Cache contexts: Confirm that the output varies by user role, language and exposed filter input where the old view did.
Compare the result set for several filter combinations, not just the default view, because the defects usually appear only when a filter is set.
Exports and feeds are Views that another system consumes, such as a CSV download, an XML feed, a partner API or a scheduled data pull. They are the most sensitive because the consuming system often expects exact field names, date formats, encodings and ordering, and a change may break an integration without any visible error on the website. On current Drupal these are rebuilt as REST, JSON:API or feed displays, or as a custom route, and the contract with the consumer must be agreed first.
- Output contract: Document each field name, data type, date format and character encoding that the consumer relies on.
- Authentication: Confirm how the old feed was protected, whether by IP allow list, a shared key or a session, and rebuild the same control.
- Pagination and volume: Check how large exports are paged and whether the consumer depends on a specific page size or order.
- Scheduling: Verify when feeds are generated and cached, and whether the consumer polls or receives a push.
- Diff testing: Run the old and new feed for the same data and compare the files byte by byte or by parsed record.
Ask the consuming team to confirm the contract in writing, because the feed owner rarely knows every field the consumer reads.
Some Views exist only because the old site lacked a search index, a reporting tool or a better content model, and they are slow, hard to maintain or no longer used. These can be retired, replaced by a search index such as Search API with Solr, or rebuilt as a custom query where a View is the wrong tool. Deciding this before the build avoids recreating complex joins that the new site does not need.
- Usage evidence: Check page views, feed requests and inbound links for each View in the old site's logs before deciding anything.
- Search replacement: Consider a search index when the View mainly filters or sorts text, facets or large result sets.
- Custom query: Use a custom service for logic that a View would express awkwardly, and keep its access checks explicit.
- Redirects: Map any retired listing URL to its replacement so that inbound links and search rankings are kept.
- Stakeholder sign-off: Record each retirement with the owner who accepts that the output will change.
For each retired or replaced View, confirm the owner has approved the change and that the replacement returns the records the business still needs.
Documented tools for moving content and checking Views
Drupal 7 Views do not travel with the content, so the tools below cover two jobs: moving the underlying data and configuration into the new site, and proving that each listing and export still behaves as it did before cutover. Each card names one tool or practice and the check it supports.
Core Migrate API and Migrate Drupal
The core Migrate API, with the Migrate Drupal and Migrate Drupal UI modules, is the documented path for moving a Drupal 7 site into a new Drupal installation. It carries content, fields and configuration that migrate, but it does not recreate Views. Your inventory of listings and exports should be built from the Drupal 7 site, not from what the new site happens to show after the run. Confirm which Drupal 7 source plugins are available for your installed modules before planning the content work.
Drush for running the upgrade
Drush runs the migration from the command line, which makes runs repeatable and easier to record in a change log. Use the same command sequence on each rehearsal so that differences between runs point to real changes in data rather than operator steps. Keep the Drupal 7 database snapshot tied to each run so you can compare the source and destination side by side.
Contributed Views migration modules
Contributed modules may attempt to convert Drupal 7 Views into Drupal configuration, but Drupal.org lists this as a best-effort process with known issues. Treat any converted View as a draft. Compare filters, sorts, contextual arguments, pager settings and access rules against the original, because a converted View can look correct while returning different rows. Check each module's compatibility with your target Drupal version on its project page before adopting it.
Drupal 7 site as the reference
Keep the Drupal 7 site running in a read-only copy until cutover is complete, and use it as the baseline for every check. For each listing and export, record the expected result set for a fixed set of test queries, including edge cases such as unpublished content, empty categories and users with restricted access. Without a live reference, teams end up comparing the new site with their memory of the old one.
Output comparison before cutover
Compare the rebuilt listings and exports with the Drupal 7 reference before any DNS or traffic change. Compare row counts, sort order, field values, date formatting, and the files produced by each export, using the same account roles as the original users. Record every difference and decide whether it is a defect, an accepted change or a rule that must be rebuilt. Ask your partner to show this evidence as part of acceptance.
Module compatibility confirmation
Module compatibility changes over time, so confirm the supported Drupal core versions for every migration and Views module on its Drupal.org project page on the day you plan the work. Record the version you tested against, and repeat the confirmation if the target core version changes. A module that worked on your rehearsal environment may not match the release you deploy.
How the rebuild sequence runs alongside a parallel run and cutover
The sequence keeps the Drupal 7 site authoritative while Views are rebuilt in priority order, then proves the new site matches the old one before URLs, feeds and consumers move across. Each phase closes with a written check so the decommission decision rests on evidence rather than assumption.
Inventory every View and assign an owner
Export the list of Views from the Drupal 7 site, including page and block displays, feeds, exports and any Views used by other modules or templates. For each one, record its path, displays, filters, sorts, contextual arguments and the team that depends on it. Assign a named business owner and a technical owner to each item. The step is done when the inventory has an owner and a criticality rating for every View, and when the list has been signed off by the content and operations leads.
Map external consumers of each View
Identify which Views feed something outside the site: RSS readers, partner systems, spreadsheets pulling CSV exports, search crawlers, mobile apps or scheduled reports. Record the exact URL, format, query parameters and the consuming party for each. Confirm with those consumers which fields and paths they rely on, since a feed that changes its URL or markup breaks silently. The step is done when every external consumer is listed against a View and has a confirmed contact.
Migrate content into a staging Drupal site
Run the content migration into a staging Drupal site built on current core, using the Migrate API and the migration modules chosen for the project. Keep entity structure, field names and taxonomy identifiers stable where possible, because rebuilt Views depend on them. Record the migration run and rollback results. The step is done when the staging content matches the agreed field mapping and the record counts for each content type have been reconciled against the Drupal 7 source.
Rebuild Views in priority order
Rebuild Views on the staging site in the order set by business criticality and external consumers. Start with those that drive revenue, regulatory reporting or feeds that other systems read, then move to internal listings and low-use exports. Each View is built manually with its filters, sorts, arguments, pager and access rules, and any best-effort migrated version is checked rather than trusted. The step is done when each prioritized View has been built, reviewed by its business owner and marked in the inventory.
Compare rebuilt Views with the Drupal 7 site
For each rebuilt View, compare the result set with the Drupal 7 output for the same inputs. Check row counts, sort order, pager behavior, exposed filter results, access for each role and the markup of feeds and exports. Record differences and decide whether each is a defect or an intended change approved by the owner. The step is done when every prioritized View has a comparison record with no open unexplained differences.
Run the parallel site and check both
Run the Drupal 7 site and the new site side by side for a period agreed with the business owners, with the same content entered or synchronized as the project defines. Compare pages, feeds and exports on both sites, and log any consumer that reads from the old site. Monitor errors and access logs on both. The step is done when the agreed parallel period ends with no open defects in the prioritized Views and every external consumer has confirmed it reads correctly from the new site.
Cut over URLs and feeds
Switch public URLs, feed addresses and export endpoints to the new site, with redirects from the old paths where the paths changed. Update external consumers to the new endpoints in agreement with their owners, and keep the Drupal 7 site available in read-only form for rollback. Verify each cutover item with a live check after the switch. The step is done when each URL and feed returns the expected content on the new site and each consumer has confirmed the change.
Decommission the Drupal 7 site
Once the cutover has been stable and the owners have signed off, archive the Drupal 7 database, files and configuration under the retention rules your organization sets. Remove the old site from DNS, routing and monitoring, and revoke its credentials. Confirm that any remaining Drupal 7 security exposure has been closed by taking the site offline. The step is done when the archive has been verified, access has been removed and the inventory is closed with a signed record of each View's final state.
What usually goes wrong with Views rebuilds
Views rebuilds rarely fail loudly. The problems that cause the most damage are the ones that look finished on the new site, such as a feed that still returns data but in a different shape, or a listing that shows the right titles to the wrong audience. Each risk below has a check to run before the old site is switched off.
Exports and feeds break silently
A Drupal 7 view that served an XML, CSV or JSON feed may be the only thing a partner, finance team or search engine reads. If the rebuilt feed uses a different path, field order, date format or element name, the consumer may keep polling and ingest bad or empty data without raising an error. Prevention: record each export's URL, format and consumer during inventory, then compare byte-level output from the old and new sites for the same sample records and notify each owner before cutover.
Migrated Views that return different results
Best-effort Views migration modules can copy a view that renders correctly but filters, sorts or relationships differently from the original. A missing exposed filter, an altered sort order or a changed join can return a plausible list with the wrong rows. Prevention: for every critical listing, define expected row counts and sample items from the Drupal 7 site, then compare the rebuilt view against them rather than checking that the page loads.
Access rules lost in translation
A view inherits its display access and query tags from the site, but custom access plugins, role-based arguments and node access grants may not carry over as intended. Content that was restricted on Drupal 7 can appear in a rebuilt listing, or a listing can go empty for editors who relied on it. Prevention: test each view as anonymous, authenticated, editor and administrator accounts, and confirm that node access modules and role settings on the new site match the old permission model.
Theme-dependent markup that no longer displays
Many Drupal 7 views rely on theme template overrides, custom CSS classes or field formatters that were written for the old theme. Because themes must be rebuilt rather than migrated, the view may render unstyled, hide fields or show raw markup after cutover. Prevention: list every view template override and class dependency in the inventory, then assign each one to the new theme build so that its output is reviewed in the target theme, not only in the default one.
Forgotten blocks left out of regions
Views are often published as blocks placed in specific regions, and those placements do not always move with the view. A sidebar listing, footer teaser or promotional block can disappear from the new layout without any error, and the gap may not be noticed until a stakeholder asks. Prevention: export a list of every block placement and region from the Drupal 7 site, map each one to a rebuilt block on the new site, and check the rendered pages against that list on each key template.
Caching and pager differences
Pager type, items per page, caching settings and cache tags can change behavior after a rebuild. A listing may show stale results after content is edited, or a pager may return a different page count, which breaks bookmarks, links and any downstream system that expects a fixed page size. Prevention: document each view's pager and cache settings before the move, test editing a node and confirming the listing updates, and verify that paged URLs and item counts match the original site.
What drives the cost and duration of rebuilding Views
This table lists the factors that change how much work it takes to rebuild Drupal 7 Views on the new site, who is paid for each activity, and what is one-time versus recurring. Use it to check a written quote against the inventory your team has actually completed. The main takeaway is that the Views inventory and the number of consumers who must sign off usually matter more than the number of Views themselves.
| Driver or cost component | Why it changes cost or effort | What to ask for in a quote |
|---|---|---|
| Number of Views and displays | Each display (page, block, feed, attachment) is configured separately, so a view with several displays costs more than its count suggests. | Quote per view and per display, listed from the inventory. |
| Relationships and contextual filters | Joins to users, taxonomy, Media or other entities need checking against the migrated data model, which adds build and test time. | Which views depend on relationships, and how those relationships were validated. |
| Exposed filters and sorting | Each exposed filter needs its own widget, default and query behavior, and each combination needs a test case. | Count of exposed filters and whether AJAX or pager behavior must match the old site. |
| External exports and feeds | RSS, CSV, XML and other feeds carry format, URL and consumer contracts that must match what partners already parse. | Number of export URLs, their formats, and whether each path must stay identical. |
| Consumers needing test sign-off | Each downstream team, partner or department that reads a listing or export adds a review cycle and a fix round. | Who signs off each view, how many review rounds are included, and who coordinates them. |
| Theme rebuild scope | Views output is styled by the theme, and Drupal 7 themes must be rebuilt, so markup and template work often depends on the same listings. | Whether theme templates for listings are in scope and how they are priced separately. |
| Quality of content and field migration | Views built on fields that migrated poorly need data fixes before the listing can be rebuilt or tested. | Results of a migration validation run, and who fixes source data issues. |
| Inventory work | Someone must list every view, display, export and consumer. This is often done by the client's team, a partner, or both. | Whether inventory is a separate fixed-scope deliverable, and what the client must provide. |
| Rebuild and testing | Build hours scale with the drivers above. Testing covers listings, filters, exports and consumer checks. | Hours or deliverables per view, test scripts, and acceptance criteria agreed in writing. |
| Ongoing maintenance | Listings change as editors and consumers ask for new filters or feeds. This recurs after launch and is separate from the one-time rebuild. | Whether a retainer or support hours cover view changes, and the response terms. |
Questions teams ask before rebuilding Drupal 7 Views
Can a Views migration module rebuild our Drupal 7 Views automatically?
Not reliably. Views are not migrated from Drupal 6 or 7 and must be created manually on the destination site, and the contributed Views migration modules make only a best-effort attempt. Expect some listings to arrive with filters, sorts or relationships missing or altered, and expect exports and feeds to need the most checking. Use any module output as a starting point for the rebuild, not as the finished configuration. Confirm the current state of any module against the Drupal.org known issues page before you plan around it.
How do we estimate the effort to rebuild Views without a price list?
Effort follows from the inventory, not from a rate card. Count the Views, then grade each one by its complexity: number of displays (page, block, feed, export), exposed filters, contextual arguments, relationships, custom handlers and any permission or caching rules. Add the consumers of each View, because a feed read by an external system needs more verification than a sidebar block. Ask any partner for a fixed-scope quote built from that list, with each View named, the work for each stated, and the testing included. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
What does our internal team need to provide during a Views rebuild?
The rebuild depends on people who know what each View is for. Name an owner for each listing or export, a consumer contact for every feed or report that other systems or teams read, and a sign-off person who accepts the rebuilt output. Without those roles, teams argue about correct filters after launch. Owners should also confirm which fields, sort orders and access rules are still wanted, because a legacy View often carries settings nobody uses. Plan these reviews into your calendar early, since they are often the longest part of the work.
Can our own developers rebuild the Views without a partner?
Often yes, if they know Drupal site building and the Views interface well. Views are configured in the user interface and exported as configuration, so a capable Drupal developer can rebuild most listings without custom code. The harder cases are Views that depend on custom PHP handlers, complex relationships from Drupal 7 field logic, or exports that must match an existing file format exactly. Assess your team against the inventory: if most Views are standard listings and the team has time, the work can stay in-house. If several feeds depend on custom code, a partner can take those on in a fixed scope.
How should we test exports and feeds after the Views rebuild?
Compare the output, not just the screen. For each export or feed, capture a sample from the Drupal 7 site and the new site using the same records, then diff the field names, field order, date formats, encoding, row counts and empty values. Check sorting and pagination on large datasets, and test any filter that uses user roles or contextual arguments with accounts of each role. Ask each consumer contact to confirm the output works in the system that reads it. Keep the comparison scripts and sign-off records, since they support later changes and audits.
What happens if a Drupal 7 site stays in service longer than planned?
Security risk rises and cost usually follows. Drupal 7 security support ended on January 5, 2025, according to Drupal.org. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet, so that is one option to price against the migration. Any Views kept on the old site also keep its old modules and PHP environment in service. Ask any vendor what extended support covers, how long it lasts and what it does not include, and compare that with the cost of the rebuild.
What drives the timeline for rebuilding Views?
The timeline follows the number of Views, their consumers and the sign-off cycle. Simple listings are quick to rebuild, while feeds, exports and Views that other teams depend on take longer to verify. Delays usually come from unclear owners, consumers who are not available for testing, and changes requested mid-build. Agree the inventory and sign-off dates before the build starts, and ask any partner to show how each phase depends on those inputs.
How DeployOpen scopes and delivers the Views rebuild
DeployOpen plans, implements, customizes and documents self-hosted open-source platforms inside the client's own infrastructure, including the Drupal sites that come out of a Drupal 7 migration. For the Views rebuild, the work starts with an inventory rather than a build. Every View on the Drupal 7 source site is listed with its base table, its display types (page, block, feed, data export), its exposed filters, sort order, pager settings, contextual arguments and the roles that can reach it. Each entry is then tagged as a listing that the new site must reproduce, an export that downstream systems depend on, or a leftover that nobody uses. The inventory is the input to the scope, so it should be finished before any estimate is discussed.
Most DeployOpen engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and the written quote follows from that scope. For a Views rebuild, the scope document should name each View to be rebuilt, the target content types and fields in the new site, the export formats and URLs that must keep working, and who verifies that a rebuilt listing returns the same records as the original. Ask any partner to quote per View or per feed group, state which exports need a stable URL or file format, and say whether the output of any best-effort Views migration module will be reviewed or discarded. Ongoing support after launch, including changes to rebuilt Views as content models evolve, is available as a retainer rather than being folded into the one-time build.
