How to Rebuild CRM Reports in HubSpot After Migration

The first Monday after go-live is when most teams find out whether a CRM migration worked. The data is in. The pipeline looks right. Then the sales leader opens the forecast and the number is different from last week's, and nobody can say why. Reports are rarely part of the data migration plan, yet they are what leadership uses to judge it.

This guide explains how to rebuild CRM reports in HubSpot after a migration: why reports need attention, how to audit what you have, how to map source fields to HubSpot properties, how to rebuild sales dashboards and pipeline reports, how to validate filters and historical comparisons, and the issues that most often cause totals to change.

Why CRM Reports Need Attention After Migration

Reports do not migrate. They are definitions built on top of data: which records to include, which fields to group by, which dates to filter on and how to calculate the result. None of that moves when records are exported from one CRM and imported into another. Each report has to be rebuilt in HubSpot's own reporting tools.

Rebuilding is also not the same as recreating. A report in Salesforce, Dynamics 365 or Zoho CRM depends on that system's objects, fields and logic. HubSpot uses a different data model, so a report that counted "Opportunities in Stage 3 with Probability above 50%" needs to be translated into HubSpot deal stages, properties and filters. If the translation is loose, the numbers drift.

Three things make CRM reporting migration harder than it first looks:

• Definitions live in people's heads. Teams often know what a report shows but not exactly how it is filtered. "Pipeline" can mean open deals, open deals closing this quarter, or open deals above a certain stage.
• History behaves differently. Some HubSpot properties are calculated from activity inside HubSpot, so they start at the import date for migrated records.
• Automatic values change. HubSpot sets some properties automatically, such as deal probability and close date, and those rules may differ from the source system.

Planning for reports before go-live avoids a week of confused leadership meetings afterwards.

Audit Existing Reports and Metrics

Start with what people actually use, not with everything that exists. Most CRMs accumulate hundreds of reports, and many have not been opened in months.

Ask each team lead for the reports and dashboards they review weekly, the ones that go to leadership or the board, and any that feed other systems or spreadsheets. Then pull usage data from the source CRM where available, and list every report that has been run recently.

For each report you keep, write a short definition:

• Metric: What is measured, such as count of deals, sum of amount or average days to close.
• Object and filters: Which records are included, and every filter that applies.
• Grouping: How results are broken down, such as by owner, stage, month or source.
• Date logic: Which date drives the report, such as create date, close date or stage entry date.
• Owner and audience: Who maintains it and who reads it.
• Last known value: The current result in the source CRM, saved before cutover.

The last item is easy to skip and expensive to miss. Without a saved baseline, there is no way to prove the rebuilt report is correct.

Turn the definitions into a short metrics glossary that sales, marketing and finance all agree on. A single page that states what counts as pipeline, what counts as a new customer and which date decides the month a deal belongs to will settle more arguments after go-live than any dashboard. It also gives the person rebuilding reports in HubSpot a clear specification to work from.

The rows above are examples to show the shape of the audit, not data from a real account.

Map Source CRM Fields to HubSpot Properties

Reports depend on fields. Before rebuilding anything, confirm that every field a report uses has a HubSpot property, and that the values mean the same thing.

Use the field mapping from the data migration as the starting point, then check each report's fields against it:

• Stages: Map each source stage to a HubSpot deal stage. If two source stages were merged into one, any report that grouped by stage will change.
• Picklists and categories: Lead source, industry, region and loss reason must use the same values, or grouped reports will split or merge categories.
• Amounts: Confirm which amount the report used. HubSpot has Amount, Amount in company currency and Weighted amount, which HubSpot describes as the amount multiplied by deal probability.
• Dates: Confirm which date the source report used and that the matching HubSpot property was populated during import.
• Owners and teams: Every owner must exist in HubSpot, and teams must be set up if reports group by team.

Pay special attention to calculated fields. A source CRM formula field becomes either a HubSpot calculation property or a static value imported at migration time. A static value will not update, so any report that relies on it will drift as records change.

Marketing reports need the same care as sales reports. Reports on lead source, campaign influence and conversion rates often depend on lifecycle stage and on the dates contacts reached each stage. Map the source CRM's lead status and lead stage fields to HubSpot's lifecycle stage and lead status properties explicitly, and agree how imported contacts should be staged. A contact imported as a customer with no history will count as a new customer on the import date unless the original dates are stored somewhere reports can use.

Historical stage data needs its own decision. HubSpot's stage calculated properties, such as date entered and time in stage, are described by HubSpot as read-only properties that update automatically based on movement through a pipeline. Because they are driven by movement inside HubSpot, they cannot show stage changes that happened in the old CRM. If reports need historical stage dates, import them into custom date properties and build those reports on the custom properties.

Rebuild Sales Dashboards and Pipeline Reports

With definitions and properties in place, rebuild in HubSpot's tools. HubSpot dashboard setup usually combines three types of report:

• Prebuilt sales reports. HubSpot's sales analytics suite includes reports such as deal pipeline waterfall, deal change history, deal funnel, deal velocity, time spent in deal stage, weighted pipeline forecast and historical snapshots. HubSpot lists these under Sales Hub Starter, Professional or Enterprise.
• Custom reports. HubSpot's custom report builder lets you choose a primary data source, add more data sources and filter with ALL, ANY or custom logic. HubSpot lists it as a Professional and Enterprise feature.
• The forecast tool. For forecasting by category or pipeline, HubSpot's forecast tool is often a better fit than a custom report.

Organize dashboards by audience rather than by report type. A sales leadership dashboard, a manager dashboard and a rep dashboard each answer different questions. HubSpot lets you filter a whole dashboard by date range, owner, team or pipeline, which reduces the number of separate reports you need.

Build in a sensible order. Start with the one or two dashboards leadership reviews every week, validate them, and share them before go-live so leaders see familiar numbers on day one. Then rebuild manager and rep dashboards, and finally the long tail of occasional reports. Resist recreating every legacy report: if nobody can name its audience, leave it out and see whether anyone asks for it.

Dashboards are easier to get right when they are planned with the migration rather than after it. Our support for HubSpot reporting and dashboards is part of the migration work, so the reports leadership relies on are rebuilt and checked before go-live.

Set permissions as you build. HubSpot dashboards can be private to their owner or shared with everyone, and HubSpot notes that sharing with specific users and teams is an Enterprise feature. HubSpot also limits the number of reports per dashboard by subscription, so plan larger dashboards accordingly.

Validate Filters and Historical Comparisons

Validation proves that each rebuilt report gives the same answer as the source. Compare against the baseline values saved during the audit, for the same period and the same filters.

When a total does not match, investigate in order: filters first, then field mapping, then the data itself. Most differences come from a filter that was interpreted differently, not from missing data. HubSpot notes that date filters use the account time zone and that its weeks run Monday to Sunday, which can move records across boundaries if the source system used a different setting.

Run the old and new reports side by side for at least one full reporting cycle if you can, such as a month or a quarter close. Keep the source CRM in read-only mode during that period so the baseline does not move. Each week, compare the headline numbers and record any gap. A parallel run catches problems that a single comparison misses, such as a workflow that changes a property after import or a filter that only matters at quarter end.

Keep a log of every difference and its explanation. Leadership will accept a change in a number if they understand the reason. They will not accept a number that changed without one.

HubSpot reports refresh with new data every two hours, according to HubSpot, so allow for that before rechecking a total after a correction.

Common Reporting Migration Issues

The same issues cause most sales reporting migration problems:

• Close dates reset. HubSpot states that when a deal moves to a closed won or closed lost stage, the close date is set to that day. Make sure imported closed deals carry their original close date, and check a sample after import.
• Deal probability stops updating. HubSpot notes that manual edits, imports and integration updates to deal probability stop it from updating automatically on stage changes. Avoid importing probability unless you intend to manage it by hand.
• Stage history starts at import. Stage calculated properties reflect movement inside HubSpot only. Use custom date properties for historical stage dates.
• Merged categories. Combining stages or picklist values during migration changes every report grouped by them.
• Missing owners. Records imported without an owner drop out of owner reports.
• Static calculated values. Imported formula results do not update, so totals drift over time.
• Different time zones and fiscal settings. Month and quarter boundaries can shift records between periods.

Most of these issues are cheaper to prevent than to fix. Add a reporting check to the migration test plan, so a sample import is validated against a handful of key reports before the full import runs. A problem found on a few hundred test records takes minutes to correct. The same problem found on the full dataset after go-live can take days, and it costs trust in the new system.

If you want help with the reporting side of a migration as well as the data, OneMetric's HubSpot CRM migration services include report audits, rebuilds and validation against your source baseline. To talk through your own CRM analytics migration, get in touch with OneMetric.