A new portal can look like relief when nobody trusts the one you have. The difficult decision is deciding which problems belong to the current setup and which would follow your team into the replacement.
We recommend making that decision at the level of a business process, a data relationship and a dependency. A blanket rebuild is too large a starting assumption. A blanket cleanup can be equally unhelpful when the underlying model no longer represents how you sell or serve customers.
TLDR: Keep what still supports the business. Repair defects that you can isolate and verify. Consider rebuilding a defined part of the system when the current design cannot support an agreed requirement without unacceptable complexity. Before choosing a new portal, account for the records, relationships, history and connected systems you would need to preserve.
Start with a short description of the work that is failing. “HubSpot is messy” is an observation. “The account owner cannot identify the active contract when a renewal arrives” is a requirement you can test.
For each affected process, write the trigger, the person responsible, the information required and the expected outcome. Then identify a representative record that works and one that does not. Avoid changing either while you are still establishing the baseline.
If you do not yet have that inventory, use the HubSpot portal audit checklist first. The audit identifies what needs attention. This decision should use those findings to choose the smallest defensible scope of change.
HubSpot describes its CRM in terms of objects, records, properties and associations; the objects available in an account can depend on its subscription. HubSpot data model documentation explains those building blocks.
That distinction matters when you describe the problem. Missing values in a useful property are different from a property being asked to represent several conflicting concepts. An incorrect relationship is different from a model with no agreed place for that relationship at all.
We would ask your team to answer three questions before discussing replacement:
A “no” should trigger deeper design work. It should not automatically trigger a portal migration.
For this decision, we use cleanup to mean correcting records or rules within a usable design. Rebuilding means changing the design of a component, such as a process or data relationship. Neither label tells you whether the whole portal should be replaced.
Use this comparison as a decision aid, not a universal scoring formula.
| Path | When to consider it | Evidence to require |
|---|---|---|
| Keep | The process meets an agreed requirement and the remaining issue is cosmetic or low priority. | An owner confirms the expected behavior and accepts the documented limitation. |
| Repair | The design is usable, and you can identify a bounded defect or missing rule. | A defined change set, an approval boundary and a test showing the defect is resolved. |
| Rebuild a component | A process or relationship needs a different design to meet the requirement. | A replacement model, dependency map, migration plan and acceptance test for the affected component. |
| Replace the portal | A documented constraint makes a new portal a credible option after component alternatives have been assessed. | A complete transfer and cutover assessment, including what will not transfer and who accepts that loss. |
The fourth option deserves its own business case. Do not present it as the natural next step after a disappointing dashboard review.
Hypothetical example: Your sales team uses a field called “Customer status” to mean both contract status and onboarding progress. A customer can have an active contract while onboarding is delayed, so the values conflict.
First, write separate definitions for the two concepts. Next, inspect how the current values are used in reports, automation, imports and connected systems. Propose a mapping for existing records, including ambiguous values that require a person to review them.
This might justify rebuilding that part of the model while keeping the portal and unaffected processes. It does not, by itself, justify moving every record to a new account.
Now change the assumption: the relevant information cannot be represented by the proposed design in the account you intend to use. That is a different decision. Investigate supported alternatives and subscription constraints before approving either a workaround or a rebuild. The example illustrates the reasoning, not a claim about a particular account configuration.
A rebuild proposal should tell you what survives, not only what gets created. Ask for a preservation register covering records, identifiers, relationships, relevant history, consent information, integrations, reports and user access. Specify which items are essential to operations and which need a separate retention decision.
For each item, record the source, destination, transfer method, validation method and accountable role. Anything with an unknown transfer path remains an unresolved dependency. An export file alone should not be accepted as proof that the replacement will behave correctly.
Before approving work, ask who can pause a problematic change, how the team would restore the previous state where possible, and which actions are not safely reversible. Review that boundary with the person who owns the business process, not only the person performing the configuration.
Ask your team to compare repair and rebuild proposals against the same requirement and preservation register. Include the work to understand dependencies, correct or transfer data, test connected processes, train users and maintain the result. Keep any confirmed subscription changes separate from implementation work.
A lower configuration estimate does not settle the decision if it leaves essential transfer or validation work unpriced. Equally, a more ambitious rebuild needs a reason beyond a cleaner diagram. Ask which business requirement the added work satisfies and what evidence supports that choice.
Record unknown costs as unknown. Do not assume every cleanup is inexpensive or every rebuild is justified. Use the pilot to reduce the uncertainty you can test before approving the larger commitment.
Pick one affected process and agree on a limited pilot. Record the baseline, the authorized changes and the acceptance checks before execution. After the pilot, use the evidence to decide whether to continue, adjust the design or stop.
For operational symptoms that still need diagnosis, our guide to common HubSpot issues provides additional context. Keep diagnosis separate from permission to change the system.
We recommend discussing the decision in the context of HubSpot operations and CRM architecture, with clear ownership of the business rules. The useful output is a justified scope, not a promise that a fresh start will solve everything.
Use the HubSpot Portal Audit Scorecard to organize the findings you want to review. Bring the unresolved requirements and preservation questions to that discussion.
We would not make a new portal the default. Start by checking whether the existing design can meet the requirement and whether the defect can be isolated. If it can, assess a bounded repair before considering a replacement.
Consider a component rebuild when its design cannot represent an agreed business requirement without complexity your team is unwilling to accept. Define the replacement, its dependencies and the information you need to preserve before approving the change.
Do not accept that guarantee. Require a plan for deciding which values are trustworthy, resolving ambiguous records and preventing the same input problems from returning. Judge the proposed design through agreed examples and checks, not the fact that it is new.
Product documentation checked August 28, 2026. Confirm current account capabilities before implementing changes.