Migration › Take inventory
Step 02 of 13
15% complete
Take inventory
Before you build anything new, you count what you already have, because you cannot migrate what you haven't named. A mature AppMeasurement implementation is an attic of a decade's decisions: eVars whose meaning lives only in someone's memory, processing rules quietly rewriting values, plugins doing work nobody documented. Skip this and you'll find the gaps the worst way, when a report goes silent weeks after go-live. An afternoon spent inventorying now is the cheapest insurance the project will buy, and its output is one spreadsheet, your migration's source of truth, that every later step refers back to.
What to do
1
Do List every report suite in scope.
2
Do Export every eVar, prop, and event, names and settings (expiry, allocation, serialization).
3
Do Catalogue the things that hide: plugins & doPlugins logic, processing rules, context data variables, merchandising eVars, classifications, marketing channels.
4
Do Note downstream consumers, Data Feeds, Data Warehouse, Report Builder, Workspace projects, API consumers. They break silently if a variable moves.
⚠ Common mistake
Starting at the schema before the inventory. You then model what you remember, not what you have, and the forgotten variables resurface after launch, when they're expensive to fix.
Reality check
Most of your config, classifications, marketing channels, processing rules, segments, is report-suite-side and survives the migration untouched. Inventory tells you what's genuinely in scope versus what simply keeps working.
✓ You should have
One spreadsheet listing every variable, plugin, rule, and downstream consumer, each marked in-scope or survives-as-is.