How to Migrate from Clay to Yalc Without Breaking Pipeline

To migrate from Clay to Yalc, inventory the tables that actually drive pipeline, rebuild each one as a single markdown skill, repoint the data and sending providers, then run both stacks against the same list for two weeks before cutover. The step almost everyone botches is cutting over the same day they finish building, with no parallel window to surface the edge cases a year-old table has accumulated.

If you run Clay today and the per-step credit math, the shared-workspace politics, or the table nobody can read anymore is the thing that has to change, the rest of this page is the map. The thesis underneath it is simple. A Clay table is integration glue wearing a spreadsheet costume, and glue is the worst thing to rent. You want the data providers and the senders. You do not want to keep paying a canvas to wire them together.

What does a Clay-to-Yalc migration actually involve?

It is a workflow rewrite, not a data export. There is no "import my Clay tables" button, and you should not want one. A Clay table encodes its logic as a column graph that only renders inside Clay. Yalc encodes the same logic as a markdown skill that Claude Code reads and runs, which means the migration is the act of translating column graphs into plain-English playbooks.

One decision rule keeps this sane. Migrate workflows, never tables. A single Clay table that sources companies, enriches them, scores against ICP, and pushes survivors to a sequencer is one workflow with one input and one output. It becomes one skill, not five files. If you try to recreate Clay column-for-column you will rebuild the exact 60-column object you were trying to escape, just in a different syntax.

Why the rewrite is worth the friction comes down to what Clay charges for. As of June 2026 Clay runs a dual-credit model after its March 2026 overhaul, where Data Credits are spent every time it pulls from a provider and Actions are spent on platform operations, both billed per step rather than per contact (Clay pricing breakdown, Salesmotion, 2026). You are paying a platform margin on top of the underlying provider cost. Migrating removes that middle layer.

How do I audit my Clay tables before migrating?

Open every table and answer one question per table. What does this produce for the business. Not what it does inside Clay. What lands at the bottom.

Most workspaces hold three table archetypes. Sourcing tables that pull people or companies from a provider. Enrichment tables that take a list and add columns. Action tables that push enriched rows into a sequencer or CRM. Tag each table with its archetype, because Yalc handles each as a different skill shape, and a table that mixes all three is really three skills wearing a trench coat.

For each table worth keeping, write down four things. The trigger that fills the first column. The providers each column calls. The condition that decides which rows survive to the next step. The destination at the bottom. If a table has no destination, it is not a workflow, it is a parked spreadsheet, and parked spreadsheets do not migrate, they get archived.

The non-obvious part is gating order. Clay's own enrichment math punishes you for enriching rows you will never contact, since a multi-provider waterfall can burn well into double-digit credits per single contact before it finds a verified hit (Clay data enrichment guide, DevCommX, 2026). So during the audit, note where each table qualifies before it enriches. If qualification happens after enrichment, that is a bug you are about to fix for free in the rewrite, not a feature to faithfully reproduce.

How do I map a Clay workflow to a Yalc skill?

A Yalc skill is a markdown file that tells Claude Code what to read, which providers to call, and what to write. One workflow from your audit becomes one skill with a named input contract, the provider chain spelled out in prose, and a single defined output.

Take the qualify-and-queue workflow. In Clay that was a company list, a firmographic enrichment column, an ICP scoring column, a filter, and a push to a sequencer. In Yalc it is one file, say qualify-and-queue.md, that reads a CSV or a Notion view, calls the providers, applies the scoring rule in plain English, and writes survivors to a staging destination. The conditional logic you wired across five Clay columns ("if provider A returned a verified email, run this column, otherwise skip") collapses into one sentence the model executes. The logic gets shorter, not longer.

Clay's own docs will never sell you this angle. Readability is the deliverable. A markdown skill is greppable, diffable in git, copyable across clients, and legible to the operator a year after the person who built it has left. A column graph is none of those. When you migrate you are converting tribal knowledge that lived in one person's head into a file the whole team can read. The leads qualification skill in the public repo is the canonical example to read before you write your first one, and you can see the shape of it on the qualify leads skill page. Name your skills the way you would name a Slack channel for that workflow.

What replaces Clay's enrichment waterfall?

A two-provider stack covers what the waterfall did for almost every team. Crustdata for the people and company layer, including firmographics and signals. FullEnrich for the email and phone waterfall, which already runs its own multi-provider chain internally so you do not wire one yourself.

The translation is mechanical. Anywhere a Clay column called find_email or find_phone across a stack of providers, replace it with one FullEnrich call. Anywhere a column ran enrich_company, enrich_person, or pulled hiring or funding signals, replace it with one Crustdata call. FullEnrich queries 15 plus providers in sequence per contact and only charges on a verified hit, at roughly 1 credit for a work email, 3 for a personal email, and 10 for a mobile number (FullEnrich review, SyncGTM, 2026). FullEnrich paid plans start near $29 per month for 500 credits, with per-credit cost dropping at volume (FullEnrich pricing, Prospeo, 2026).

Here is the decision rule that matters more than the provider names. The economics of the swap depend entirely on who you already pay. Teams already buying Crustdata or FullEnrich on the side and using Clay only to wire them together get a clean cost removal at the Clay line with no new bill to absorb. Teams coming from a pure Clay setup see a smaller dollar delta and a larger ergonomic win in ownership. Run your own numbers against this before cutover so finance is not surprised.

One gotcha from the audit phase carries here. Provider keys saved inside Clay keep burning credits until you remove them. Pull the keys out of Clay on the day you start the parallel run, not the day you finish. The longer reasoning behind an API-first, markdown-configured stack lives in the open source Clay alternative writeup.

How do I repoint the sequencer without breaking deliverability?

Most Clay tables push to a sequencer at the bottom. The Yalc target is one channel, one provider, one skill that owns the handoff. For cold email, push to Instantly. For LinkedIn, push to Unipile. The skill assembles the list, picks the sender, writes the personalized body your prompt produced, and posts the campaign over the API. Replies come back through the same API so a second skill can classify them and write the result to your CRM.

The dimension Clay migration guides skip entirely is sending infrastructure, and it is where pipeline actually breaks. Since February 1, 2024, Google and Yahoo enforce bulk-sender rules on anyone sending more than 5,000 messages a day to their inboxes. You must authenticate with SPF, DKIM, and DMARC, offer one-click unsubscribe, and keep your spam complaint rate below 0.3 percent, with Google recommending you stay under 0.1 percent (Mailgun bulk sender guide, 2024). Moving sequencers is the moment to confirm your sending domains carry those records, because a cutover that fires from a freshly pointed domain with no DMARC alignment lands in spam no matter how clean the data is. Verify the auth records before the first send, not after the bounce report.

If you are choosing between cold email volume and LinkedIn-first outreach as the primary motion, the channel tradeoff is broken down in the B2B lead generation playbook.

Why run both stacks in parallel for two weeks?

Run Clay and Yalc against the same input list, same ICP, same volume, same destination, for two weeks. Two paths writing to two staging tables you read side by side every morning. The point is not to prove Yalc works. The point is to surface the edge cases your Clay table accumulated over a year and quietly patched on row 47.

This is the step the opener flagged as the one everyone botches, and the cost of skipping it is concrete. Clay tables grow weird columns. A field gets renamed slightly. A conditional gets bolted on for one stubborn segment. The person who built the patch has left. None of that is documented, and the only way to find it is to diff the new skill's output against the old table's output on real data. A migration that goes straight to cutover ships those gaps into production on Monday morning.

Keep the batch small during this window, on the order of a couple hundred prospects a day rather than thousands. You are reading for shape, not chasing volume. Expect to find a handful of real discrepancies. A Crustdata field named differently from the Clay column you copied, FullEnrich returning a personal email where Clay returned the work email, a scoring prompt that disqualifies prospects the old table kept. Fix those inside the window. Volume comes after.

What does cutover day look like?

The cutover is boring on purpose. If it feels exciting, you skipped the parallel run.

Morning

Pause every Clay workflow that touches the channels you are migrating. Confirm each Yalc skill runs cleanly against a fresh ten-row test list. Confirm Instantly and Unipile both accept the output and show the campaign queued, not errored. Pull the provider keys out of the Clay workspace so credits stop burning. Update the runbook wherever your team looks for "where does the daily send come from now" so nobody opens Clay on Monday to fix what is gone.

Afternoon

Run the first real production batch through Yalc. Watch the campaign launch. Pull the first ten replies and confirm they classify into the right inbox. Check the CRM rows landed where the skill says. Post a short note to the team on where to file bugs.

Day two through five

Sit with the system, do not start a new project. Pipeline migrations surface a quiet failure around day three. Be present to fix it the same morning instead of discovering it the following week.

What stays in Clay after the migration?

The break point is recurrence. Keep Clay for one-off enrichment pulls and ad hoc experiments. Move every recurring playbook to Yalc. A one-time enrichment of 2,000 founders for an event sponsorship is a job Clay still does well. A daily ICP qualification that runs on every new domain hitting your site wants to be a markdown file your operator can read and edit.

Some teams keep nothing in Clay, and that is also correct. The legacy self-serve tiers ran $149, $349, and $800 a month for Starter, Explorer, and Pro, with the March 2026 plans starting around $185 for Launch and $495 for Growth, billed annually (Clay pricing, Warmly, 2026). If nobody on your team will open a Clay table once a quarter, that monthly line is muscle memory you are renting. Cancel it.

Cost comparison at month one and month six

Month one is the honest moment. The annual Clay contract has not lapsed, Crustdata and FullEnrich are both billing, and operator hours run heavier because the build is fresh. Expect a temporary overlap cost while both stacks run in parallel. This shape is identical to any tooling migration in any business and it is the price of not breaking pipeline.

Month six is the interesting moment. The Clay contract is gone. Per-step credit pricing is replaced by usage that maps to provider API cost with no platform margin stacked on top, and provider billing per record is easier to forecast than per-column-run credits. Operator time compounds in your favor, because the skills written in month one are still running in month six and you have edited maybe two of them. The teams already paying for Crustdata or FullEnrich separately bank the largest dollar saving. The teams coming from pure Clay bank a smaller dollar saving and a larger ownership win. Both are real. Pick the math that fits your team and run it before cutover.