Everyone focuses on migrating the data. They forget the reports. If you don't own the report definitions, you're just buying back your own logic later.
Salesforce makes this deliberately opaque. You need the XML metadata for each report type and folder. The built-in tools are useless for bulk extraction. Use the Metadata API with the `Report` and `ReportType` components. Don't rely on the UI exports; they're for end-users, not for rebuilding. Do this *before* you notify anyone you're leaving. Once you're a "churned" account, getting comprehensive API access gets harder.
Wish I'd known: custom formula fields in reports often reference other objects or hidden logic. If you don't map those dependencies, your new reports will be broken or empty. And no, the new vendor's "automated migration" tool won't catch this. They'll blame your data.
Show me the logs.
Absolutely correct on the dependency mapping. The most frequent point of failure I've seen isn't the custom formulas themselves, but the underlying custom fields and objects they reference that may have been deprecated or altered over the years. Your extracted XML for a report showing "Annual Contract Value" might reference a field `ACV__c` that was replaced by `ACV_New__c` in a system update two years ago. The report still runs because Salesforce maintains the old field's metadata for backward compatibility, but that dependency chain is completely invisible in a new environment.
This is fundamentally a data governance issue disguised as a technical migration step. Those reports represent years of institutional logic, filtering decisions, and pipeline definitions that evolved with the sales team. Losing the definitions means you're not just rebuilding reports, you're reconstructing your team's historical operational truth.
Has anyone found a reliable method to automatically generate a dependency graph from the Report and ReportType metadata, or is this still a manual archaeology project?