A portal rarely fails outright. It degrades, and the degradation is specific enough that you can go looking for it.
Where the damage usually is
Deal stages. The pipeline was built around how the company sold at the time, and the stages got named after internal activity: Proposal Sent, Following Up, Waiting. Activity names have no exit test, so two reps put the same deal in different stages. Each stage carries a close probability, so any weighted pipeline figure built on it inherits the disagreement. Stages named for something the buyer did, which somebody else can verify, hold up better.
Properties. A portal accumulates near-duplicates over a few years. A custom Lead Source sitting next to HubSpot's Original Source. Two account owner fields. A free-text industry field alongside a dropdown that means the same thing. Reports built on one quietly disagree with reports built on the other. HubSpot's own default properties can be hidden from views but not deleted, so the work is partly consolidation and partly deciding which field is canonical and then enforcing it.
Lifecycle stage. It is a property, and several things can set it: the native automation under Settings > Objects > Contacts > Lifecycle Stage, pipeline rules, form defaults, imports, and workflows. In most portals all of those have been touched at some point and nobody can say which one is currently winning, which is why half the database sits at Lead and nothing moves it.
Associations. Contacts not linked to companies, deals not linked to the people who actually worked them, and no association labels, which are themselves a Professional and Enterprise feature so plenty of portals have never had them available. This is what makes company-level reporting impossible, and it stays invisible until somebody asks a question the data cannot answer.
Orphaned automation. Workflows still running with no owner and no documentation, some with overlapping enrollment so a contact gets two emails. Nobody turns them off because nobody can prove what they do.
Duplicates. Contacts deduplicate on email, so the same person with a work address and a personal address is two records. Companies deduplicate on primary domain, so subsidiaries split apart. Worth knowing that companies created through the API or a data sync app are not domain-deduplicated at all, which is usually the real source of company sprawl in an integrated portal. Manual merging from a record works on any plan. The duplicates manager that suggests pairs is Professional or Enterprise, and bulk merging inside it needs Data Hub Professional or Enterprise.
The order we work in
Process before configuration. Map how a deal actually moves, then rebuild the stages to match, each with a yes or no exit test.
Properties next. Pick the canonical field for each concept, merge or hide the rest, add validation where the field feeds a report.
Then associations and a deduplication pass, because reporting built on broken associations will be wrong regardless of how well the report is built.
Automation after that, and only on the administrative layer: logging, task creation, stage-based notification, internal handoff. How much of that is available depends on your tier, so it is worth confirming what your plan includes before anyone designs around a workflow.
Reports last, built on the fields you just made canonical, so the numbers reconcile when somebody checks them against the records.
If you want a second opinion
We do this for companies that already own the license. Book a call and we will tell you what we would change first.
Marketing that gets a reaction.