Consultant here. What's the one question you wish you'd asked your migration partner upfront?

Great question. The one I learned the hard way is, "Can you walk me through a specific past project where your initial data mapping assumptions were wrong, and how you corrected course mid-migration?"

You're right to be thinking about rollback and validation, but the real test is how they handle unexpected complexity when the plan meets the data. A good partner will have clear examples of how they pivoted - maybe they found legacy fields with multiple meanings, or a custom relationship that broke a standard transformation.

Ask for that story. It tells you more about their problem-solving and communication under pressure than any process deck. It also gives you a script for what to watch for in your own mapping phases.

>who exactly owns the data validation after the cutover?

That's a good one. I got burned on that once in a cloud migration, but with infrastructure. We assumed the partner was validating the deployed configs, but they thought we were. The handoff got messy.

For your data pipeline worry, I'd also ask for their method to test the ETL jobs with a full, ugly sample of your actual legacy data. Not just a clean subset. It can reveal those weird transformations you'd miss otherwise. Good luck

Your worry about the data pipeline is exactly where a lot of hidden time gets sunk! I totally agree with the advice to ask for their full, ugly data test method.

One specific question that saved my skin last year was: "How do you define and measure the *quality* of a transformed record, and what's your threshold for stopping the pipeline if quality drops?" It forced them to move past vague promises and commit to actual metrics. We ended up with a simple dashboard showing match/mismatch rates for key fields during each test run.

If they can't point to a concrete quality gate in their process, that's a red flag for your ETL robustness. It turns "don't lose historical data quality" from a hope into a checkpoint.

That's a tough spot to be in, especially when the pace feels overwhelming. You're right to focus on the data pipeline part. I'd build on what others said about validation and ask something like, "What's your specific process for auditing the ETL logic itself, not just the output, and when do we do it?"

On a recent project, we got deep into testing transformed data and it all looked correct, but we later discovered the partner had built the logic using our dev data's unique quirks. When we moved to production volume, the assumptions broke because the logic wasn't documented and reviewed independently. It became a huge scramble.

So I'd want to know exactly when and how they prove the transformation rules are sound, separate from just showing you a sample of clean results. Do they walk you through the logic mapping with your team's subject matter experts before any jobs run? That step can catch those hidden assumptions early.

That's such a real, specific trap. The "dev data quirks" problem hits every time. I'd push their point even further and ask: "How do you version and diff the transformation logic between test runs?"

I've seen partners tweak a mapping rule to handle one weird dev record, but then not flag that change. When you re-run the test on the *same* subset, it passes and you think you're golden. But the logic has already drifted from the original spec. Without a way to track those incremental 'fixes', you're not auditing the logic, you're just auditing the latest output.

A partner with a solid process can show you a changelog for the mapping rules themselves, not just the data results.

Totally feel you on the data pipeline nerves. All the suggestions here are gold. I'd add one that's been a lifesaver for me: "Can we see a real-time preview of the transformation logic applied to a messy, live record *before* any batch job runs?"

It's one thing to see a sample output CSV after the fact. It's another to point at a specific, gnarly legacy account and say "show me, step by step, how *this* becomes a Salesforce record right now." Watching that live mapping in a staging environment catches so many edge cases early. It turns their logic from a black box into a collaborative tool.

Good partners usually have a way to do this in their toolkit. If they don't, it's a sign the mapping might be too opaque until the big migration run, and that's a scary moment to find a logic error 😅

>I'm especially nervous about the data pipeline part

That's the right thing to be nervous about. Everyone else is dancing around it. Forget asking about their process. Ask them this: "What's your runbook for when your ETL job fails at 2am on cutover weekend, and what's your SLA to have it fixed?"

If they start talking about "robustness" and "monitoring" without a concrete, one-page plan, they're selling you a dream. Real pipelines break. You need to know who's on the hook, with what tools, and how fast they'll move when it's dark and you're panicking.

All this talk of validation and versioning is moot if the job itself croaks and there's no clear owner holding the pager. Seen it too many times.

You're absolutely right to zero in on the operational runbook. It's the difference between theoretical and operational resilience. However, that 2am failure scenario often hinges on a prerequisite that gets missed: the quality and granularity of the monitoring for the pipeline itself.

I'd push the question one step earlier: "What specific metrics, beyond job success/failure, will your pipeline emit during the cutover run, and where will your on-call engineer see them?" A simple failure alert is useless if it doesn't tell you *which* transformation stage died, or if it's buried in a log aggregator the partner's team can't access quickly. You need a dashboard showing record throughput, error rates per mapping rule, and validation score trends in real time. If they can't articulate that observability layer, their runbook is just a document, not an action plan.

So many great questions in this thread already! The one I'd add to your list about the data pipeline is a bit more foundational: "What's the single source of truth for our mapping rules, and how do you enforce that it stays synchronized with our actual business logic?"

I've seen projects where the partner's ETL scripts become that de facto source of truth because the initial spec document falls out of date. Then, a year later when you need to add a new field, nobody can fully explain why a certain transformation exists. You're reverse-engineering your own migration.

You want a clear answer on whether they use a dedicated mapping tool that generates the code, or if the code itself *is* the spec. If it's the latter, you need a rock-solid review process for every logic change, not just for the output. Ask to see a sample of their change documentation for a single mapping rule. That'll show you if the process is truly traceable.

The validation and monitoring others mentioned are critical for the cutover, but this traceability question is what saves you from long-term data debt.

Oh, this thread has been such a great read. Your specific worry about the ETL jobs and historical data quality really hits home.

To build on what others have said, I'd ask them, "What's your plan for mapping and migrating our *failed* or *deprecated* field logic?" Let me explain.

You can have a perfect pipeline moving clean data, but what about that old "Lead Source" picklist value you stopped using two years ago? Or the custom formula field that calculated something incorrectly for a period? A lot of historical reporting hinges on that old, sometimes messy, logic being translated faithfully, not "corrected" to a new standard. You need to know if they'll preserve those quirks intentionally or if their transformations will silently "clean up" your business history. It's a subtle point that affects forecasting and trend analysis way down the line.

I had a partner once "standardize" all our regional abbreviations, which broke five years of territory reports. That's the kind of data quality loss you don't see until long after the migration party is over.

Lots of great points here, especially about data quality gates and logic audits. Since you're already worried about the historical data quality, I'd take a step back and ask something about scope that ties into the ETL robustness.

Specifically, I'd ask, "What's your policy on 'close enough' data matches, and who gets the final say?" This sounds simple, but it's crucial. During mapping, partners often hit ambiguous legacy fields. They might propose a transformation that gets it right 95% of the time, knowing that fixing the last 5% could double the project time. You need to know if they'll flag those judgment calls for your client's review, or if they'll just make an assumption to keep things moving. That decision directly impacts how much of your historical data's nuance survives the trip.

That "who gets final say" question is crucial, but I find it's often answered with a lie of omission. They'll say "the client reviews all edge cases," but their process buries the decision in a spreadsheet footnote.

The real test is to ask for their *actual* criteria for what constitutes a "close enough" match. If they can't give you a quantifiable threshold (e.g., "we flag any mapping rule with less than 99.5% confidence based on our sample"), then "client review" just means they'll dump a thousand ambiguous cases on you two days before the deadline, forcing you to rubber-stamp their 95% solution.

Get them to show you the ticket from their last project where they escalated a mapping ambiguity. The details tell you everything.

Exactly. That logic drift is the silent killer. It's like they're editing the answer key between tests, and you only find out during the final exam.

Your changelog point is spot on. I'd push it to the actual tooling. If they're using a proper ETL platform, they should be able to show you a commit history for a mapping rule, just like a developer would for code. If they're patching scripts manually, that's a huge red flag for me.

All this talk about pipeline failure is skipping the real issue. You're nervous about ETL jobs for a *small client* moving to Salesforce? That's overkill.

The one question I'd ask: "Can we do 90% of this with Salesforce's own data loader tools and some simple scripts?" Partners love to sell complex pipelines because it locks you in. I've seen teams spend months on a "robust" migration that could've been a week of CSV imports.

Your historical data quality probably isn't that special. Most legacy CRM data is a mess. A fancy ETL won't fix that, it'll just hide the mess in a complicated transformation layer you'll never understand.