Adobe has retired the legacy Adobe Analytics Report Builder add-in and introduced a new Report Builder experience based on the Microsoft Office add-in model. This change is tied to the retirement of the Adobe Analytics 1.4 APIs and affects workbook execution, scheduled reporting, access management, and related reporting processes.
The legacy Report Builder reached end of life in June 2026. Scheduled workbooks created with the legacy add-in stopped being delivered from 1 July 2026, while the self-service migration deadline was 12 August 2026. Organisations with remaining legacy workbooks must now use Adobe Customer Support to obtain original files where necessary before completing the migration process.
Approach this change as an exercise in reporting continuity and data governance, rather than a routine software upgrade.
1. Understand the scope of the retirement
The retirement concerns the legacy Report Builder add-in, not the broader concept of extracting Adobe Analytics data into Excel. Adobe’s replacement is the new Report Builder add-in, which supports Adobe Analytics and Customer Journey Analytics.
According to Adobe’s Report Builder overview, the new add-in provides:
- Support for Windows, macOS and Excel Online.
- Improved data block creation and management.
- API 2.0 support.
- Custom dates using calendars, cell references and date mathematics.
- Familiar Excel-based report formatting.
- A conversion feature for legacy workbooks.
The deployment model is materially different. The new Report Builder is distributed through the Microsoft Store and requires the relevant permissions in the Adobe Admin Console. Microsoft Store access, Office add-in governance and internal software approval processes must therefore be considered alongside the Adobe Analytics migration itself.
Confirm which reporting users, service accounts, and desktop environments require the new add-in. Secure Microsoft Store and Office add-in approval before undertaking large-scale workbook conversion.
2. Establish the current position of every workbook
Most organisations have more Report Builder dependencies than are immediately visible. Workbooks may be stored in personal folders, shared drives, team sites, email attachments or automated reporting repositories. Some may be actively used, while others continue to run without a clear owner.
A migration inventory should record, at minimum:
- Workbook name and location.
- Business owner and technical owner.
- Adobe Analytics report suite or Customer Journey Analytics connection.
- Frequency and recipients of scheduled delivery.
- Metrics, dimensions, segments and date ranges used.
- Number of requests or data blocks.
- External Excel formulas, macros and linked files.
- Downstream uses, including board reporting, finance processes and operational dashboards.
- Required delivery date and business criticality.
- Migration status and validation result.
This inventory should distinguish between:
- Critical operational workbooks, where failed delivery could affect trading, customer management or regulatory reporting.
- Management reporting workbooks, which may require visual or formatting parity.
- Exploratory workbooks, which may be better replaced by Analysis Workspace.
- Obsolete workbooks, which can be retired rather than converted.
- Integration workbooks, which may depend on macros, linked files or other Adobe APIs.
Establish a controlled workbook register before migration. Workbooks lacking an identified owner should not be considered ready for conversion or decommissioning.
3. Assess conversion compatibility
Adobe provides a legacy workbook conversion process. The conversion feature is intended to reduce manual rebuilding, but it should not be interpreted as a guarantee of functional equivalence.
Adobe’s documentation confirms that some legacy features are not supported in the new Report Builder. The conversion assessment should therefore cover more than whether a file opens successfully.
Technical checks should include:
- Whether every data block converts successfully.
- Whether report suite or connection references remain correct.
- Whether calculated metrics and segments return the expected results.
- Whether date ranges retain their intended interpretation.
- Whether cell references continue to drive the correct requests.
- Whether hidden worksheets, named ranges and linked data are preserved.
- Whether Excel formulas depend on a specific workbook structure.
- Whether VBA macros or external connections continue to operate.
- Whether formatting remains suitable for the intended recipients.
- Whether workbook processing time remains acceptable.
Adobe’s Report Builder FAQ also documents limits relating to workbook size, API calls and processing time. A workbook may contain up to 1,000 requests, while scheduled reports can fail after four hours of processing. High request volumes may also encounter company-level API limits.
The conversion process does not solve these underlying design issues. It changes the reporting mechanism, but it does not simplify an over-complex workbook, resolve undocumented dependencies, correct inaccurate metric definitions or establish ownership.
Each workbook should be duplicated and renamed prior to conversion, in accordance with Adobe’s Report Builder overview. The original file should be retained as a reference, and all conversion changes should be documented.
4. Review scheduled reporting separately
Scheduled delivery requires particular attention because the legacy scheduling mechanism ceased to operate from 1 July 2026. A workbook that converts successfully may still fail to meet reporting requirements if its schedule, recipients or delivery method has not been recreated.
The replacement process may involve:
- Scheduling the converted workbook through the new Report Builder.
- Rebuilding delivery through Analysis Workspace.
- Exporting reports to supported cloud destinations.
- Replacing a spreadsheet report with an Analysis Workspace project.
- Moving high-volume or detailed extraction to Data Warehouse or Data Feeds.
For Analysis Workspace, Adobe supports scheduled CSV and PDF exports through Share > Schedule file export. You can review and manage scheduled projects through Components > Scheduled Projects. The relevant Adobe documentation explains the available frequencies, recipients and file formats.
CSV and PDF exports are not interchangeable with every Report Builder use case. A PDF may preserve the visible presentation of a project, while a CSV provides plain-text data. Neither necessarily reproduces a complex Excel workbook containing formulas, multiple worksheets or custom business logic.
Reconcile the workbook register against email distribution lists, scheduled project records, and stakeholder reporting calendars. Both report content and delivery processes should be tested prior to retiring any legacy schedule.
5. Review related API dependencies
Retiring legacy Report Builder is tied to the end of life of the Adobe Analytics 1.4 APIs. This creates a broader dependency review requirement.
Other systems may still rely on 1.4 APIs, including:
- Custom extraction scripts.
- Internal reporting tools.
- Scheduled data pipelines.
- Excel integrations.
- Middleware and data warehouse processes.
- Third-party reporting products.
- Monitoring or quality assurance utilities.
A Report Builder migration does not automatically identify or remediate these dependencies. A workbook can be converted successfully while a separate integration continues to depend on an unavailable or unsupported API.
Adobe’s 1.4 API end-of-life documentation and 2.0 API migration guide should be used to assess related services and determine whether each integration can move to API 2.0 or requires a different export method.
API usage should be included in the technical discovery process. Source code, scheduled jobs, service accounts, and network activity should be reviewed in addition to workbook documentation.
6. Validate data and business meaning
A technically successful migration is not sufficient. Validation must confirm that the new process continues to produce data that is accurate, complete and meaningful to its users.
A practical validation comparison should include:
- Identical reporting periods.
- Identical report suites or data connections.
- Identical segments and filters.
- Identical metrics and calculated definitions.
- Equivalent breakdowns and sorting rules.
- Expected treatment of exclusions and unavailable data.
- Reconciliation of totals at multiple levels.
- Review of rounding, formatting and blank-value behaviour.
- Confirmation of delivery timing and recipients.
- Business-owner approval for material outputs.
Classify differences rather than dismiss them. Some may result from API changes or unsupported legacy features. Others may expose pre-existing issues in tagging, segment logic, attribution settings or metric definitions.
This is where migration can provide a useful control point. Comparing old and new outputs may identify reporting drift that was not visible during routine use.
The migration approach does not solve inaccurate implementation, incomplete tagging, consent-related data loss or poorly defined business requirements. Those issues require separate assessment through an analytics data quality review and, where applicable, an Adobe Analytics implementation review.
7. A practical migration approach
A controlled programme can be structured into six stages:
Stage 1: Discover
Create the workbook and API dependency inventory. Identify owners, schedules, recipients, data sources and business criticality.
Stage 2: Classify
Assign each workbook to one of four outcomes:
- Convert.
- Rebuild in Analysis Workspace.
- Replace with another export method.
- Retire.
Stage 3: Prepare
Obtain the new Report Builder add-in, confirm Adobe permissions and secure approval for Microsoft Store deployment. Duplicate critical workbooks and document their current outputs.
Stage 4: Convert or rebuild
Use Adobe’s conversion process where appropriate. Rebuild workbooks where unsupported features, excessive complexity or changed business requirements make direct conversion unsuitable.
Stage 5: Validate
Compare outputs, test schedules and obtain approval from technical and business owners. Record variances and their explanations.
Stage 6: Govern
Retain the workbook register, migration decisions, validation evidence and ownership information. Establish a review process for future workbook creation and API usage.
Conclusion
Adobe Analytics Report Builder retirement requires a structured review of workbooks, schedules, APIs, ownership and data meaning. Conversion is an important part of the transition, but it does not replace technical discovery or validation.
The immediate priority is to identify remaining legacy dependencies, secure the supported tooling, recreate critical delivery processes and retain evidence that migrated outputs remain fit for purpose. The transition may also provide an opportunity to retire obsolete reports, simplify workbook design and improve reporting governance.
If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant
