Inheriting Pendo: what to check in the first month

You just found out you own Pendo now, and nobody left a manual. Inheriting Pendo usually means inheriting three or four years of decisions nobody wrote down, a subscription someone else signed, and at least one thing that quietly stopped working before you arrived. The job in the first month is not to learn every feature. It is to find out what is broken, what is unowned, and what is load bearing, in that order.

The clearest example I have from this year is a healthcare data company that acquired a smaller firm with its own Pendo subscription. The subscription was moved over, not deleted, so on paper everything carried across. In practice the snippet in the legacy apps still carried the old API key, so for the better part of a quarter new data went nowhere. Nobody noticed, because nobody owned it. When a report finally needed the data, the trail had gone cold and the account metadata was mapped so badly that one field meant to hold an account name held a person’s first name. The fix took one engineer an afternoon. Finding out it was needed took months.

Week one: check the install before you trust any report

An inherited instance can look healthy and be dead. Dashboards keep rendering old data, and the charts do not flag that nothing new has arrived. So before you read a single report, confirm data is flowing today.

1. Open the app you inherited, open the browser console, and run pendo.validateInstall(). Pendo’s Validate your Pendo installation article explains the output: SDK version, visitor ID, account ID, and any install warnings.
2. Run pendo.getVisitorId() and pendo.getAccountId() and check that both return the identifiers your product actually uses, not a session string or someone’s name.
3. In Pendo, go to Settings, then Subscription Settings, then the application, and open Raw Events. If the newest events are from last week, you have the API key problem or a deploy that dropped the snippet.
4. Open the Metadata tab and read the field mappings. Every field should hold what its name says. The healthcare company’s “Account Name” field holding somebody’s first name is the kind of thing you only catch by reading.

If the key is wrong, the news is better than it looks. Once data flows again, the raw events from the gap can be tagged retroactively, so you recover history rather than starting from zero. If the install itself is shaky, our Pendo implementation and cleanup work usually starts right here, with the snippet, not with guides.

Inheriting Pendo means inheriting ghost owners

Every inherited system has owners who set something up and then changed roles, left, or stopped looking. The symptom is a dashboard nobody has opened since it was built, a guide still running for a feature that shipped two versions ago, and a feedback queue with no one assigned. A fintech I started with this fall had been paying for Pendo through a full contract term with two internal teams who had never agreed on who owned it, and the renewal was weeks away before anyone asked what it had produced.

Write the ownership table in week one. It is the single most useful document you will produce, and it takes an hour of conversations, not a week in the settings menu.

Some of those names will be yours. Not all of them should be. For each row where the previous owner is gone and nobody wants it, decide whether the thing is retired or adopted. Leaving it blank is how the next person inherits the same mess from you.

Read what exists before you change anything

Log in and look, for real, before you touch a setting. Open every dashboard and check which have been viewed in the last 90 days. Click through the guides that are live and ask who they were for. Check which segments reference metadata fields that no longer exist. You will usually find at least one dashboard that has not been opened since it was made. That is normal, not a crisis.

Do not delete anything in week one. You do not yet know what is load bearing. Archiving an obviously dead dashboard is fine; deleting the segment a renewal report depends on is a bad second week. The legacy apps at the healthcare company had been set up for marketing and webinar announcements rather than product analytics, and an executive directive years earlier had stopped anyone collecting NPS or CSAT. None of that was wrong to keep. It was wrong to assume it told you anything about product usage.

Then put a light rule around what happens next

Governance for an inherited instance is three answers written where everyone can find them: who can create dashboards and guides, who approves what gets tracked, and how often the whole setup gets reviewed. You do not need a committee. You need one owner and a 30-minute check-in on the calendar each quarter. The governance basics for a small Pendo team cover the short version.

Then write three things you will do in the next 90 days. Not everything you could do, three. Fix the install if it is broken. Retire the dashboards nobody uses. Build the one report the team that asked loudest has been waiting for. A roadmap with three items gets done. If you are starting cold rather than inheriting, the first 90 days for a new Pendo admin is the companion piece, and it assumes a clean instance where this one assumes a messy one.

What to tell the person who asks why it took so long

Someone will ask why the data has a gap, or why the previous team’s dashboards do not match the new numbers. The answer is the ownership table and the validation steps above. Show that the install is now verified, that each area has a name next to it, and that the gap is being back-filled from raw events. That is a more credible story than a rebuild, and it is usually true: most inherited instances need pruning and ownership, not a fresh start. Teams that want someone to carry the ownership row permanently are what Pendo managed services are for.

Questions people ask

How long should I wait before changing an inherited Pendo instance?

Validate the install on day one, because a dead snippet costs you data every day it sits. Then give yourself two to three weeks of reading and conversations before you delete or rebuild anything. Archiving dashboards nobody has opened in 90 days is fine sooner.

What if nobody documented anything about our Pendo setup?

That is the common case, not a dealbreaker. The ownership table and the install checks above become the documentation that should have existed. Five 20-minute conversations with the people who use the dashboards tell you more than a week alone in the settings.

Do I need to rebuild Pendo after inheriting it?

Almost never. Most inherited instances need a corrected install, pruning, and a named owner per area. Save a rebuild for the rare case where the data itself cannot be trusted, for example a visitor ID that was never unique.

If you inherited an instance and the first validation step came back wrong, that is worth a conversation before anything else. Book a free Pendo strategy call and we will walk the ownership table with you and tell you what to fix first.