How to Fix a Broken HubSpot Portal Without Replatforming

A broken HubSpot does not usually need a replatform. It needs a 12-week cleanup, in this order. The instinct to rip-and-replace is almost always wrong — and it is the single most expensive mistake we see teams make when their portal stops working.

The math is simple. A replatform costs you six months of calendar time, $50K–$250K in implementation fees, and the data integrity hit of migrating the same dirty data into a fresh portal. A targeted remediation costs you 12 weeks, a fraction of the budget, and leaves the historical data in place where the executive team can still query it. Yet “we need a new portal” is the first thing CMOs say when their HubSpot fails the audit checklist at 25 points.

This post is the order to do remediation in. We have run this 12-week sequence on roughly 30 portals; the order matters more than the individual fixes. Skipping ahead — say, rebuilding dashboards in week 3 — almost always means redoing them in week 11.

The replatform trap

Why do teams reach for replatform when remediation would work? Three reasons, all psychological.

The portal feels poisoned. When trust has collapsed, “fix it” feels naive and “burn it down” feels decisive. The new portal is a clean slate; the old one carries the scent of the previous regime that broke it.

The previous implementer is still around. Remediating a portal means living with somebody else’s choices and quietly correcting them. Replatforming means starting fresh, which is politically easier — nobody’s ego is on the line.

The proposal in front of the CMO is for a replatform. Most agencies prefer replatform projects because they are bigger budgets and longer engagements. The proposal you have on your desk reflects the agency’s incentive structure, not your actual need.

The reality: roughly 70% of “we need a new portal” instincts we encounter turn out to be remediation cases. The portal is fine — the configuration is broken in a small number of identifiable layers, and those layers can be fixed without a migration.

The 30% that genuinely need a replatform are the ones with structural problems — wrong data centre region, wrong account hierarchy (multiple separate portals when there should be one, or vice versa), or a fundamental architectural choice made years ago that cannot be unwound in flight. We will get to those at the end.

Week 1–2: data triage (the cleanup-vs-rip-out call)

Before any cleanup, you need to know what you are working with. Weeks 1 and 2 are diagnosis, not action.

The deliverables of week 1–2:

The 50-point audit run and scored. (The full checklist is here.)
A duplicate report at contact, company, and deal level, with totals and percentages.
A property inventory, flagging dead properties (zero fill rate over 12 months) for deletion.
A workflow inventory, flagging zero-trigger workflows (haven’t fired in 90+ days).
A “data confidence” map: which datasets do we trust, which are corrupted, which are unknown.

The output is a remediation plan with a single, sharp call: clean the data in place, or do a controlled re-import. Most cases are clean-in-place. The rip-out cases are usually portals where contact dedup is over 25%, lifecycle stages were redefined three times in the last two years, and the company-record taxonomy is fundamentally wrong.

The trap to avoid in week 2: starting the cleanup. The temptation is overwhelming — you have just spent two weeks finding problems, the impulse to fix one is hard to resist. Resist. The order matters.

Week 3–4: workflow audit and orphan removal

The workflow layer is where the most visible damage lives, and it is also the easiest to fix early — because most of what you find is dead code.

The week 3–4 work:

Identify orphans. Workflows with no recent triggers, no documented owner, or no path back to a current business motion. Pause them, do not delete — paused workflows can be revived; deleted ones cannot.
Identify duplicates. Workflows that overlap (two workflows both creating MQLs from form submissions, with different criteria). Pick a winner, document the choice, pause the loser.
Identify silent failures. Workflows that are active but produced unexpected results in the last 30 days — high error rate, high “not enrolled” count, or contact records stuck in step 1 for weeks.
Document survivors. Every workflow that lives through the cull gets a one-line description of what it does and who owns it. This becomes the source-of-truth doc for the team.

Expect the workflow count to drop by 40–60%. That is normal. The portal we audited last quarter had 312 active workflows; after week 4 it had 137. The remaining 137 each had an owner, a description, and a clear business reason.

Workflow cleanup feels like progress because it is visible — the team can see the inventory shrinking. Use that momentum carefully; the next week is the hard one.

Week 5–6: lifecycle stage redefinition (the alignment week)

This is the week the implementation succeeds or fails. Lifecycle stages — Lead, MQL, SQL, Opportunity, Customer — are the spine of every report and the source of every CMO-vs-VP-Sales fight.

The work is half configuration, half conversation:

Define each stage with an entry criterion and an exit criterion, in writing. “Marketing-Qualified Lead” means what, exactly? Score above 60? Demo requested? Sales-accepted? Pick one definition; document it.
Get sign-off from CMO and VP Sales on the same document. Not in a meeting. In a one-page Google Doc both of them have edited and approved. This is the artifact the rest of the company will reference for the next two years.
Build the workflow that enforces stage progression. Stages should not be manually editable for the lifecycle field. Workflow-driven, with documented exceptions for edge cases.
Run a one-time backfill to bring historical contacts into the new stage definition, with a flag indicating “migrated under the new model.”

The reason this is the hardest week: it requires CMO and VP Sales to agree on a definition, which they have probably been arguing about implicitly for a year. The remediation lead has to facilitate that conversation, not duck it. We have seen more remediations stall here than at any other phase.

The pattern that breaks the deadlock: get one quarter of historical closed-won deals, walk back the lifecycle journey of each, and use that data to settle the definition. Closed-won is the ground truth that nobody can argue with.

Week 7–8: pipeline and forecasting reset

With lifecycle stages settled, the pipeline can be rebuilt on a foundation that holds.

Week 7–8 work:

Pipeline stage definitions, written. Same exercise as lifecycle, but for the deal pipeline. “Discovery” needs an entry criterion (“rep has booked a discovery call”) and an exit criterion (“rep has identified champion + budget”).
Stage probability recalibration. Pull historical close rates per stage from the last 4–6 quarters. Set probabilities to match. Most portals have stages locked at 10/25/50/75/90 — almost never the actual close rates.
Required deal properties at each stage. Stage gating prevents deals advancing without the data the next stage needs. Without it, late-stage deals are missing exactly the fields forecast depends on.
Forecast configuration. HubSpot’s forecast tool tied to the recalibrated probabilities. Run last quarter’s data through it as a backtest — if the forecast variance is over 25%, the configuration is still wrong.

The deliverable that matters: forecast variance under 15% on the most recent closed quarter. If you can hit that, the sales team can start trusting the dashboard again — which is the precondition for week 9.

Week 9–10: dashboard truth restoration

By now the underlying data is clean enough that dashboards can be rebuilt without lying. This is where most teams want to start; doing it ninth is what makes the difference between dashboards that work and dashboards that get rebuilt in Excel six weeks later.

Week 9–10 work:

Audit the existing dashboard inventory. How many are there? Who owns each? Which are still being viewed? Most portals have 50+ dashboards by this stage of life and 6 of them are actually used.
Cull aggressively. Target 5–15 dashboards total. One executive dashboard, one per Hub leader, one per critical motion (pipeline review, lead funnel, customer health). Everything else gets archived.
Rebuild the survivors against the new data model. Old dashboards built on old lifecycle definitions show old numbers. They have to be rebuilt, not migrated.
Reconcile across dashboards. The MQL number on the marketing dashboard equals the MQL number on the funnel dashboard equals the MQL number on the exec dashboard. If they disagree, find which property is broken upstream.

The test of week 10: the executive team looks at the dashboards in a Monday standup and nobody asks “is this number right?” Everybody just reads the number. That is the bar.

Week 11–12: adoption re-launch

This is the week that gets skipped most often, and it is the week that determines whether the remediation holds or rots back into the same broken state inside a year.

The team has spent 10 weeks watching the portal get better. They have not yet been asked to use it differently. Without an explicit re-launch, they will keep their old habits — the Excel exports, the personal-WhatsApp threads, the side-channel approvals.

Week 11–12 is about getting the team to fall back in love with the portal:

Hands-on training, not videos. A 90-minute working session per team — sales, marketing, CS — running the new dashboards and workflows live. The implementer is in the room, answering questions in real time.
Document the “what changed” memo. A one-pager per role: “These are the five things that are different now. These are the three habits to drop.” Sent to every team member, signed off by their manager.
Set a 30/60/90 check-in cadence. Calendar invites already on the books for week 16, 20, 24. The remediation does not end at week 12 — it has a tail.
Pick one win to celebrate publicly. “Pipeline forecast is now accurate within 12% — we have not had that in two years.” Make the recovery visible.

If you skip this week, you bought yourself a clean portal that the team will quietly stop using. We have seen it happen. The configuration was right; the adoption was wrong; eight months later the team had built their parallel Excel system again.

The 3 cases where replatform IS the right call

Most “broken portal” cases are remediations. Three categories actually need a replatform.

Wrong data centre region. If your portal is on US storage and you have grown into a customer base where EU residency is now a contractual requirement, the data centre cannot be migrated. You need a new EU portal and a controlled data import. This is a replatform.

Wrong portal architecture. Some teams set up multiple separate portals (one per region, one per business unit) when a single portal with teams and partitioning would have been correct — or vice versa. Unwinding the architecture in flight is harder than starting clean.

Foundational object-model errors. If your custom object schema was built on the wrong primary association (companies linked to deals via a custom property instead of the native association, for example), every report, workflow, and integration sits on top of that wrong choice. Sometimes the cleanest path forward is a new portal with the right model.

Outside those three, remediation will almost always be the right answer. The math heavily favours it: 12 weeks against 6 months, a fraction of the cost, and you keep your data history intact.

What to do next

If your portal scored below 35 on the audit checklist, the next decision is remediation vs. replatform. Walk through the three replatform cases above honestly. If none of them apply, you are looking at a 12-week remediation, in the order above.

If you have already decided you want help running the remediation, book a free 30-min consultation with your audit score and the top three failures from the checklist. We will come back with a 12-week plan mapped to your specific portal — not a templated one.

The right partner is the one who tells you not to replatform when you do not need to. Most will tell you the opposite, because the opposite is a bigger invoice.