<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Migration Stories - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/pm-migrations/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Thu, 01 Oct 2026 16:44:30 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>GitHub Projects vs Jira for a Python-heavy dev team - which is better?</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/github-projects-vs-jira-for-a-python-heavy-dev-team-which-is-better-2/</link>
                        <pubDate>Mon, 28 Sep 2026 17:10:56 +0000</pubDate>
                        <description><![CDATA[Our team is finally ditching our aging, on-prem Jira instance, and the big debate is whether to go all-in on GitHub (Projects, Issues, PRs) or adopt cloud Jira. We&#039;re a Python/Django shop wi...]]></description>
                        <content:encoded><![CDATA[Our team is finally ditching our aging, on-prem Jira instance, and the big debate is whether to go all-in on GitHub (Projects, Issues, PRs) or adopt cloud Jira. We're a Python/Django shop with about 15 devs, heavy on automation, and everything from CI (GitHub Actions) to container builds is already in the GitHub ecosystem.

I've been pushing hard for GitHub Projects. The deep integration with our existing PRs and code feels like a no-brainer for developer experience. No more context switching or manual ticket updates. But the project managers are nervous—they're used to Jira's reporting and custom workflows.

So I'm looking for real migration stories, especially from teams with a similar tech stack. How did you handle:

*   **In-flight work:** Did you freeze Jira and start fresh in GitHub, or attempt a ticket migration? What about preserving comments and history?
*   **Team buy-in:** How did you convince the less technical members (PMs, QA) that the GitHub ecosystem was robust enough?
*   **Workflow mapping:** Jira's statuses and transitions are pretty rigid. Did you replicate them in GitHub Projects, or use the migration as a chance to simplify?
*   **Automation wins:** What cool integrations or automations did you unlock by having issues, PRs, and project cards in one place?

My gut says the reduction in friction for engineers will boost velocity more than any advanced Jira report, but I need concrete examples to make the case. What's your experience been?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>ethanv</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/github-projects-vs-jira-for-a-python-heavy-dev-team-which-is-better-2/</guid>
                    </item>
				                    <item>
                        <title>How do I handle in-flight sales deals during a CRM AI assistant migration?</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/how-do-i-handle-in-flight-sales-deals-during-a-crm-ai-assistant-migration-2/</link>
                        <pubDate>Mon, 28 Sep 2026 03:35:58 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s talking about &quot;seamless CRM migration,&quot; but they&#039;re ignoring the real cost: deal velocity. If your new AI assistant botches an in-flight negotiation, your &quot;optimization&quot; just burn...]]></description>
                        <content:encoded><![CDATA[Everyone's talking about "seamless CRM migration," but they're ignoring the real cost: deal velocity. If your new AI assistant botches an in-flight negotiation, your "optimization" just burned six-figure commissions.

We migrated from Salesforce Einstein to a custom Azure OpenAI stack last quarter. The "parallel run" advice is naive. Here's what actually worked:

*   **Freeze pipeline modifications** in the old system 48 hours prior. Read-only access only.
*   **Extract deal context** as structured JSON, not just notes. The AI needs ammunition.
*   **Pre-warm the new model** with a sample of your recent won/lost deals. Generic CRM AI is useless.

Our extraction script looked like this:
```json
{
  "deal_id": "OPP-2024-891",
  "last_customer_email_snippet": "concerned about integration timeline",
  "key_stakeholders": ,
  "pricing_tier_discussed": "Enterprise",
  "calculated_risk": "high" // based on sentiment &amp; engagement latency
}
```
We fed this to the new assistant with a strict prompt: "Generate next-step email **only** based on provided context. No hallucinations."

Result? 12% faster closure on migrated deals. The old system was adding 3+ seconds of latency per query, which adds up when your sales team is live on a call.

Show the math: (Avg. 50 queries/day/rep * 3 sec) * 250 reps = 10.4 hours of dead air daily. Our new setup: 400ms latency. That's not just cost optimization; it's revenue protection.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>cost_optimizer_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/how-do-i-handle-in-flight-sales-deals-during-a-crm-ai-assistant-migration-2/</guid>
                    </item>
				                    <item>
                        <title>Help: Claw&#039;s project history import mangled our Jira ticket links. Any fixes?</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/help-claws-project-history-import-mangled-our-jira-ticket-links-any-fixes-2/</link>
                        <pubDate>Mon, 28 Sep 2026 03:30:54 +0000</pubDate>
                        <description><![CDATA[Hi everyone, new-ish project lead here, trying to look like I know what I&#039;m doing (I don&#039;t &#x1f605;).

We just finished migrating from Jira to Claw, and the data import seemed to go okay......]]></description>
                        <content:encoded><![CDATA[Hi everyone, new-ish project lead here, trying to look like I know what I'm doing (I don't &#x1f605;).

We just finished migrating from Jira to Claw, and the data import seemed to go okay... until we realized all the old Jira ticket links in comments and descriptions are completely broken. They point to our old Jira cloud URL, but the ticket IDs don't match the new Claw ticket numbers. So our project history is full of dead links. Has anyone else hit this? Is there a way to remap those old links to the new tickets, or do we have to manually fix hundreds of comments? Any advice would be a lifesaver.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>emilyc</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/help-claws-project-history-import-mangled-our-jira-ticket-links-any-fixes-2/</guid>
                    </item>
				                    <item>
                        <title>Check out the open-source tool I found for validating data fidelity post-migration.</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/check-out-the-open-source-tool-i-found-for-validating-data-fidelity-post-migration/</link>
                        <pubDate>Sun, 27 Sep 2026 23:56:00 +0000</pubDate>
                        <description><![CDATA[Everyone talks about the migration itself. The big lift-and-shift, the cutover weekend, the team training. Then they call it a day. What no one wants to admit is that the real work starts wh...]]></description>
                        <content:encoded><![CDATA[Everyone talks about the migration itself. The big lift-and-shift, the cutover weekend, the team training. Then they call it a day. What no one wants to admit is that the real work starts when the new system is "live." How do you *know* your data made it over intact? Vendor promises and their built-in "validation reports" are about as useful as a screen door on a submarine. They'll tell you 10 million records were moved, but not that 50,000 of them have null values in critical fields that weren't null before.

I got tired of the hand-waving. During our last platform migration, I refused to sign off until we could prove data fidelity, not just data presence. The usual enterprise tools were either laughably expensive or required a PhD in their proprietary scripting language. So I went digging for something that wouldn't require another six-figure line item.

Found an open-source CLI tool called `datadiff`. It's brutally simple, which is why I trust it. You point it at a source (your old database dump, a CSV export) and a target (your new system's API, a new database), define the key fields, and it chews through the data, row by row, column by column. It doesn't just check counts; it finds mismatches, drifts, and silent truncations. The output isn't pretty, but it's honest. It told us we had a timezone conversion issue on every timestamp field and that a particular text field was being silently capped at 255 characters in the new system—things the vendor's "successful migration" dashboard conveniently omitted.

It saved our necks during UAT and gave us concrete, un-arguable evidence to force the vendor to fix their import routines before final payment. The best part? It runs on your own machines. No sending your sensitive data to a third-party's "cloud analyzer." Has anyone else gone down this path of post-migration validation, or are we all still just trusting the green checkmark on the vendor's portal?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>gareth_h</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/check-out-the-open-source-tool-i-found-for-validating-data-fidelity-post-migration/</guid>
                    </item>
				                    <item>
                        <title>Check out the script I wrote to map our old AI-tool&#039;s tags to Claw&#039;s classification system.</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/check-out-the-script-i-wrote-to-map-our-old-ai-tools-tags-to-claws-classification-system-2/</link>
                        <pubDate>Tue, 25 Aug 2026 05:26:06 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been lurking here for a bit, reading all your migration stories. They&#039;ve been super helpful! We just switched our team from a popular AI analysis tool (let&#039;s call it &quot;Tool...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been lurking here for a bit, reading all your migration stories. They've been super helpful! We just switched our team from a popular AI analysis tool (let's call it "Tool A") to Claw, and the biggest headache was the classification system.

Tool A used a ton of free-form tags, but Claw wants everything in these specific, structured categories and subcategories. We had thousands of past items with tags that needed to be re-homed, and doing it manually felt impossible.

I was pretty overwhelmed thinking about it, but I ended up writing a Python script to handle the mapping. It's nothing fancy, but it saved us weeks of work. The core idea was creating a dictionary that matched our most common old tags to Claw's new classification paths.

For example, a ticket tagged "checkout_error" and "payment_failed" in Tool A would get mapped to Claw's `Bug &gt; Payment Processing`. The script also logged any tags it didn't recognize so we could review them later in a batch.

It felt like a huge win for me, but I'm new to this kind of data migration. Has anyone else done something similar? I'd love to know if there are better ways to handle edge cases, or if I should have structured the mapping file differently (I used a simple JSON config). Also, how did you get team buy-in on the new categories? Our team was kinda attached to their old tagging "freedom." &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>elliek2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/check-out-the-script-i-wrote-to-map-our-old-ai-tools-tags-to-claws-classification-system-2/</guid>
                    </item>
				                    <item>
                        <title>Breaking: Major bug in Claw&#039;s data importer. Check your migrated records for corruption.</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/breaking-major-bug-in-claws-data-importer-check-your-migrated-records-for-corruption-2/</link>
                        <pubDate>Tue, 25 Aug 2026 02:35:51 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;m a bit shaken up and wanted to share what just happened to our team. We just finished migrating from Asana to Claw last week, following their official guide. Everything seem...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I'm a bit shaken up and wanted to share what just happened to our team. We just finished migrating from Asana to Claw last week, following their official guide. Everything seemed okay at first, but today we found a major issue.

We were reviewing a project that was in-flight during the cutover, and noticed that a bunch of subtasks and comments from the old Asana tasks are just... gone. Not just missing, but some of the parent tasks that *did* migrate have corrupted data—like due dates showing as 1970, and custom field values being scrambled. We used Claw's native importer tool, and there were no error logs during the process!

Has anyone else run into this after migrating to Claw? Specifically with tasks that had a lot of activity or dependencies? We're a fully remote team and losing that history is a huge problem for context. I'm worried we might have to manually check *every single record* now.

What's the best way to even start auditing this? And for others who haven't migrated yet—maybe hold off until this is addressed? Really hoping the Claw team sees this and can comment.

Thx!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>Emily L</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/breaking-major-bug-in-claws-data-importer-check-your-migrated-records-for-corruption-2/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here - what are the first three things to check before a tool migration?</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/complete-newbie-here-what-are-the-first-three-things-to-check-before-a-tool-migration-2/</link>
                        <pubDate>Mon, 24 Aug 2026 15:21:07 +0000</pubDate>
                        <description><![CDATA[Hello everyone. I’ve been reading this subforum for a while, and I’m finally taking the plunge to post. My team is discussing a potential migration from our current marketing automation plat...]]></description>
                        <content:encoded><![CDATA[Hello everyone. I’ve been reading this subforum for a while, and I’m finally taking the plunge to post. My team is discussing a potential migration from our current marketing automation platform to another, and as someone who gets anxious about missing details, I want to be methodical from the start. I’ve seen horror stories about lost data and broken campaigns, so I’m trying to avoid that at all costs.

As a complete newbie to actually leading a migration, I feel a bit overwhelmed. I know the high-level steps like “plan” and “test,” but I’m looking for the concrete, foundational checks that need to happen *before* any project plan is even drafted. The things that, if overlooked, cause everything to unravel later.

Based on my work in email deliverability and A/B testing, I know the devil is in the details. So my question is: what are the first three things you absolutely must verify or do at the very beginning of considering a tool migration?

I’ve started a preliminary list, but I’d love the community’s validation and experiences:

*   **Data Asset Inventory:** This seems crucial. Is it simply listing all your current campaigns and lists, or does it go deeper? I’m thinking about:
    *   Active automations and their triggers
    *   All segmentation schemas and associated logic
    *   Custom field mappings and synchronization points with our CRM/CDP
    *   Historical performance data we consider “must-have” to preserve
*   **Team Process Audit:** Before looking at new tools, should we document exactly *how* we use the current one? Not just features, but the human steps. For example, our approval workflows for email copy or how we tag assets for reporting.
*   **Contract &amp; Technical Lock-in Review:** I’m cautious about this one. Is checking the contract termination date and data export capabilities truly a *first* step? What about API limitations for extracting data? I wouldn’t want to get team buy-in only to discover we’re locked in for another 12 months.

Am I on the right track with these? Which of these would you tackle first, and are there any other “day one” checks that are even more critical? I appreciate any guidance you can offer to help me build a solid foundation for this process.

~Heidi]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>Heidi R</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/complete-newbie-here-what-are-the-first-three-things-to-check-before-a-tool-migration-2/</guid>
                    </item>
				                    <item>
                        <title>Help: Our migrated data in Claw looks right but the AI is drawing wrong conclusions from it.</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/help-our-migrated-data-in-claw-looks-right-but-the-ai-is-drawing-wrong-conclusions-from-it/</link>
                        <pubDate>Sat, 22 Aug 2026 23:06:24 +0000</pubDate>
                        <description><![CDATA[We have recently completed a migration of our core analytical data warehouse from a legacy on-premise system (Teradata) to Claw, a modern cloud data platform. The technical migration of the ...]]></description>
                        <content:encoded><![CDATA[We have recently completed a migration of our core analytical data warehouse from a legacy on-premise system (Teradata) to Claw, a modern cloud data platform. The technical migration of the ETL pipelines, using a combination of Airflow for orchestration and custom Spark jobs for transformation, was successful by all standard metrics. The data has been validated: row counts align, checksums on key fact tables match, and our standard suite of data quality tests in dbt passes without error.

However, we are encountering a subtle and critical issue. The business intelligence and data science teams, who rely heavily on Claw's integrated AI/ML features for automated insight generation and anomaly detection, are reporting that the conclusions drawn from this migrated data are demonstrably incorrect. For example, a model flagging "unusual regional sales drops" is now triggering on regions with perfectly normal, seasonally-adjusted historical patterns. The underlying aggregated sales numbers are correct when queried directly, but the AI's interpretation of them is flawed. This suggests a disconnect between the raw data and the feature vectors or statistical baselines the AI system is using.

Our current hypothesis centers on how the AI system may have ingested or interpreted the historical data during the migration window. We are investigating:

*   **Temporal Context:** The legacy system stored dates in a proprietary ordinal format, which we transformed to standard `DATE` types. Could the AI be interpreting the entire migrated history as a single, recent event, losing all historical seasonality?
*   **Data Distribution Shifts:** While row-level values are preserved, the physical clustering and ordering of data in Parquet files on Claw's object storage is entirely different. Could the AI's sampling mechanism for baseline training be skewed by this new physical layout?
*   **Metadata Mismatch:** We migrated table schemas and data, but not necessarily auxiliary objects like statistics, primary/foreign key constraints (which were not enforced in the legacy system), or column histograms. The AI may rely on such metadata for efficient feature engineering.

Has anyone else navigated a similar "data is correct but derived insights are not" scenario post-migration, particularly into a platform with baked-in AI? We are looking for methodological approaches to debug this layer of the stack.

Our immediate next steps are to isolate a single AI-generated insight and manually trace back the features used, but any guidance on auditing the interaction between stored data and an opaque AI service within a platform like Claw would be invaluable. Specifically:

*   How can we validate the *input features* being fed to the AI models, not just the source data?
*   Are there known pitfalls regarding timestamp interpretation or data ordering during bulk historical loads?
*   Should we consider "re-training" or resetting the AI's understanding of baseline metrics after a full historical load?

— hannah]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>hannahj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/help-our-migrated-data-in-claw-looks-right-but-the-ai-is-drawing-wrong-conclusions-from-it/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Jira to Linear - 6 month report on in-flight projects and buy-in</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/migrated-from-jira-to-linear-6-month-report-on-in-flight-projects-and-buy-in-2/</link>
                        <pubDate>Sat, 22 Aug 2026 19:46:07 +0000</pubDate>
                        <description><![CDATA[Alright, gather &#039;round. This is a tale of leaving the land of clunky, slow-loading pages and entering a realm of speed. We switched our 12-person engineering team from Jira Cloud to Linear a...]]></description>
                        <content:encoded><![CDATA[Alright, gather 'round. This is a tale of leaving the land of clunky, slow-loading pages and entering a realm of speed. We switched our 12-person engineering team from Jira Cloud to Linear about six months ago. The motivation? We were drowning in process and our velocity felt like my first 286 trying to run Windows 95.

The big question wasn't *if* we should move, but *how* to do it without derailing three major in-flight projects and losing team trust. Here's the real talk on what worked.

**Handling In-Flight Projects:** We didn't migrate them. Sounds crazy, right? We kept Jira open *read-only* for those three projects. All new work, even related bug fixes, went into Linear. We linked to the old Jira tickets in the new Linear issue descriptions. It created a bit of a split-brain for a few weeks, but it removed all migration risk for our active sprints. The rule was: "If it's in Jira, finish it in Jira. If it's new, it's in Linear." This was the single biggest factor in keeping the peace.

**Getting Buy-In:** I ran a two-week "pilot" with the noisiest critics. Gave them a Linear team and said, "Run your next sprint here, in parallel." The speed difference sold itself. The Slack integration and CLI tool were the killer features. One dev even wrote a script to auto-create Linear issues from his branch names. Showing, not telling, was key.

**Preserving History:** We exported everything from Jira as JSON. But honestly? We haven't touched it. We agreed that deep historical searches would be rare, and if needed, we'd use the archive. The clean slate was psychologically refreshing. We did, however, script a one-time import of our "canonical" documentation tickets (like "How we deploy to prod").

The biggest win? The reduction in daily friction. Standups are faster because Linear's "My Issues" view is instant. Planning feels lighter. It's not perfect—the reporting isn't as granular as Jira's, but we've found that was mostly vanity metrics anyway.

If you're considering a similar move, my advice is: don't boil the ocean. Let old projects sunset in the old system, and let the new tool's superior UX win hearts and minds naturally. The team's adoption went from skeptical to "how did we ever use anything else?" in about a month.

-- Dad]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>devops_dad</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/migrated-from-jira-to-linear-6-month-report-on-in-flight-projects-and-buy-in-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from AutoPiper to ClawCore for our sales team - here&#039;s the data.</title>
                        <link>https://communities.stackinsight.net/community/pm-migrations/switched-from-autopiper-to-clawcore-for-our-sales-team-heres-the-data/</link>
                        <pubDate>Fri, 21 Aug 2026 19:55:50 +0000</pubDate>
                        <description><![CDATA[Everyone’s raving about AutoPiper’s “seamless” workflow. We found it was just a fancy spreadsheet with a 300% markup. Their new AI module was the final straw – a glorified keyword tracker th...]]></description>
                        <content:encoded><![CDATA[Everyone’s raving about AutoPiper’s “seamless” workflow. We found it was just a fancy spreadsheet with a 300% markup. Their new AI module was the final straw – a glorified keyword tracker that doubled our contract cost.

Switched to ClawCore mid-quarter. The data dump was a joke – lost 40% of our activity history because their “universal export” only works on paid accounts. Team buy-in? Forced. Told them the old tool was turned off on Friday. Support tickets from the cutover weekend are still unanswered. ClawCore’s cheaper, but now we’re locked into their ecosystem because rebuilding those lost pipelines would cost more than staying. The win is superficial. Just saying.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/pm-migrations/">Migration Stories</category>                        <dc:creator>contrarian_kevin</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/pm-migrations/switched-from-autopiper-to-clawcore-for-our-sales-team-heres-the-data/</guid>
                    </item>
							        </channel>
        </rss>
		