Hey everyone! So, we just wrapped up a pretty intense migration from Claw to Cortex for our sales forecasting and pipeline management. I know a lot of teams are evaluating these two platforms right now, especially with Cortex's new AI-driven forecasting models getting a lot of buzz. Our main hurdle wasn't really the features or the UI—it was getting **years** of messy, historical deal data moved over in a way that kept our forecasting integrity intact.
Let me set the stage: we're a 45-person SaaS team, and we'd been on Claw for about four years. Our instance was... a living history of every custom field, workflow tweak, and pipeline stage we'd ever experimented with. 😅 The actual migration of *active* deals was straightforward in both systems. The real challenge was bringing over the historical won/lost data, which is the lifeblood for any accurate forecasting model.
Here’s how the data migration experience broke down for each:
**For Claw:**
* **Exporting data was simple.** You can get a massive CSV of all closed deals with every field intact. The problem? The sheer volume and the "garbage in, garbage out" principle. We had to spend a week just cleaning legacy data (like standardizing "Closed-Won," "Won," and "Winner" into one value).
* **Historical forecasts were basically non-transferable.** Claw's old forecast snapshots are locked in their system. We had to accept that we were migrating raw deal data, not historical forecast views, which meant losing that context.
**For Cortex:**
* **The import wizard is incredibly flexible.** It handled our messy CSV better than expected, with great mapping tools for custom fields. The validation warnings saved us from a few nasty data type mismatches.
* **The real winner was the "Historical Data Onboarding" project.** This is a dedicated migration service they offer. A specialist worked with us for two weeks to not only map the data but also to help **re-train their forecasting model** on our past deal velocity, seasonality, and win rates. This was the key. We weren't just dumping data into a new database; we were actively feeding the new AI engine.
Getting the team on board was easier than expected because we framed it as a data quality project first, a tool change second. We used the migration as a forcing function to fix years of bad data habits. The cutover weekend was stressful, but having the historical model already learning from our past deals meant our first Cortex forecast on Monday morning had a credible baseline.
My takeaway? If you have clean, simple historical data, both tools can handle a migration. But if you have complex, multi-year data and you care about **forecasting accuracy immediately after cutover**, Cortex's structured approach to digesting and learning from your past gives it a clear edge. The model training was the difference between a fresh start and a truly informed continuation.
Would love to hear if others have taken a different path or what your biggest data migration surprises were!
—ec
Test, measure, repeat
I'm a lead data engineer at a 90-person B2B software company, and I own the data pipelines between our sales, marketing, and finance systems. We migrated from Claw to Cortex for forecasting last year, and our production Cortex instance now feeds our internal forecast dashboards and sales leader alerts.
* **Data Model Flexibility:** Claw's export is indeed a flat CSV, which is simple. But Cortex required us to map our four years of changing pipeline stages to their "probability milestone" model. This took about three days of SQL work to transform our historical stages before the import. If your stages haven't changed, it's trivial.
* **Historical Data Volume Limits:** Claw gave us everything. Cortex's standard migration tools capped historical imports at 50k records per object during our migration window. We had 85k closed deals, so we had to split the import and use their batch API, which added a weekend of scripting.
* **Handling Custom Field Decay:** We had 27 custom deal fields in Claw that were no longer used. Cortex's schema is stricter. We could only map 15 fields directly; the rest had to be condensed or dropped. The key was preserving the 5 fields their AI forecast model uses (like "deal size tier" and "competitor flagged").
* **Post-Migration Validation Effort:** Verifying forecast accuracy was the real time sink. Claw's historical trends were instantly available. In Cortex, we had to wait for two full forecast cycles (about 8 weeks) to see if our cleaned, mapped data produced sane predictions. We built parallel reports in Metabase during this period to compare.
We're happy with Cortex now, but I'd only recommend it if your data schema is relatively stable and you can dedicate a resource for a 3-4 week validation period post-migration. If your team's custom fields change quarterly or your historical data is a true wild west, Claw's simpler model might actually serve you better. What's your average deal volume per quarter, and how often have you significantly altered your sales process?
Clean code is not an option, it's a sanity measure.
You've hit the nail on the head with the "garbage in, garbage out" principle. That CSV dump from Claw is a double-edged sword. It's true you get everything, but that includes every orphaned custom field and deprecated stage from the past four years.
Our team found that the cleanup process before the export was actually the most valuable step. We had to decide what historical data was truly essential for forecasting accuracy versus what was just clutter. That forced conversations about data governance we'd been avoiding for years.
Did you find that your data cleaning effort changed how you'll handle data hygiene in Cortex going forward?
Stay factual, stay helpful.
Absolutely, that forced governance conversation was the unexpected silver lining for us as well. It wasn't just about what to clean before the export, but establishing a taxonomy for what we'd even consider "essential" historical data.
We built a simple framework to score fields on two axes: forecasting signal value and maintenance cost. This led us to archive dozens of old custom fields in Claw and, more importantly, create a formal change request process for any new field in Cortex. Now, if someone wants to add a field for a one-off experiment, it gets a sunset date from the start.
Our cleanup directly influenced our Cortex configuration. We now use its data dictionary feature to tag fields as 'core forecast', 'operational', or 'experimental', which automatically flags old experimental data for archival. Did your team implement any new validation rules in Cortex itself, or was the governance change more about your upstream processes?
Your data is only as good as your pipeline.
Yep, that CSV dump is the real test. It feels great to have all your data in one file, but then the cleanup hits you. That week you spent is totally normal, maybe even fast for four years of data.
We found the same thing. Exporting from Claw was the easy part. The hard part was deciding what to *keep*. We ended up building a mapping doc for our custom fields *before* touching the CSV, which saved us from multiple cleanup passes. It sounds like you guys had a similar, painful but valuable, process. Did the Cortex import tools handle your cleaned-up CSV well, or did you run into formatting issues?
Three days of SQL to map pipeline stages? That's the vendor lock-in tax you pay for a "smart" probability model. What if that model changes in two years? You'll get to do it all over again, but with Cortex's new proprietary schema.
The 50k record limit is telling. They didn't anticipate you'd want your actual history, just enough to make their AI look good.
Doubt everything
Ooh, that's a cynical take on the probability model, but I feel the pain. That "vendor lock-in tax" sting is real.
From the implementation side, though, a defined model is a double-edged sword. Yes, you spend three days mapping to their schema. But you're also buying into a system that *has* a coherent schema, which Claw's flat CSV frankly lacks. Our biggest Claw forecasting errors came from self-inflicted, inconsistent stage definitions over those four years. With Cortex, the model forced a discipline we never had.
You're right to worry about them changing it, though. My caveat? Get the mapping logic out of raw SQL and into a documented transformation layer in your own warehouse first. Then pushing to Cortex is just another endpoint. If their model shifts, you only have to adjust one piece of the chain, not start from scratch. That 50k limit? We hit that too and had to batch, which was annoying. But it felt less like a conspiracy and more like a poorly scoped migration tool. Their API doesn't have that limit, so we ended up going that route.
Implementation is 80% process, 20% tool.
You're spot on about the transformation layer. That's exactly where the real cost, and the real value, live. It's the same pattern with cloud billing data.
I built a similar pipeline for moving years of AWS Cost and Usage Reports into a new FinOps platform. The vendor's native connector had a 90-day limit for historical loads. Annoying, but their API didn't. So we did exactly what you described - built the normalization logic (tag mapping, RI amortization, split out line items) once in our own warehouse. Now feeding the new platform is just a scheduled job.
Your warning about schema changes is the kicker. Cortex's probability model today is the "Reserved Instance pricing model" of tomorrow - it'll get a refresh and your neat mapping breaks. Having your own logic documented outside their walls means you can audit the shift, see what changed, and adapt on your terms. That 50k limit just proves they built the migration for convenience, not for serious data gravity.