How to Migrate from Clay to Yalc Without Breaking Pipeline

The first time we moved a client off Clay, we did it on a Friday and broke the Monday send. Twelve hundred prospects, no enriched emails, the sequencer firing into the void. Nobody got fired. We rebuilt the workflow in Yalc that weekend, and the same client has run from one prompt ever since. Every migration we have done since then follows the playbook below, because the lesson stuck.

If you are an operator running Clay today and you have decided that the per credit pricing, the shared workspace politics, or the table that nobody can read anymore is the thing that has to change, this is the migration map. Eight steps. Concrete examples. The gotchas that bit us in production so they do not bite you.

Pre-migration audit: what your Clay tables actually do

Before you touch Yalc, sit down with your Clay workspace and answer one question per table: what is this table actually doing in the business. Not what it does inside Clay. What it produces.

Most Clay workspaces contain three types of tables. Sourcing tables that pull people or companies from a provider. Enrichment tables that take a list and add columns. Action tables that push the enriched rows into a sequencer or a CRM. You need to know which is which before you migrate, because Yalc handles each of them as a different kind of skill.

Open every table, expand the column descriptions, and write down four things. The trigger that fills the first column. The providers each column calls (Apollo, Crustdata, OpenAI prompts, scrapers, web visits). The condition that decides which rows survive to the next column. The destination at the bottom of the table. If a table has no clear destination, it is not a workflow, it is a spreadsheet. Park those for now.

The output of this audit is a list of three to ten Clay workflows that actually drive pipeline. Migrate those first. The rest can wait, or stay in Clay forever. Nobody has to win every table.

Mapping Clay tables to Yalc skills

Yalc does not have tables. It has skills. A skill is a markdown file that tells Claude Code what inputs to read, what providers to call, what output to write. Each Clay workflow you identified in the audit becomes one Yalc skill, not one file per column.

Think of it this way. A Clay table that takes a company list, enriches with firmographics, scores against ICP, and pushes the survivors to a sequencer is one workflow. In Yalc, that becomes one skill, say qualify-and-queue.md, with a clear input contract (a CSV of companies or a Notion view), the provider chain spelled out in the skill body, and a defined output (a CSV pushed to your sequencer, or a row in a Notion staging database).

The conceptual shift is the harder part of the migration. In Clay you are wiring columns. In Yalc you are writing the playbook in plain English and the system runs it. That is also the whole reason this migration is worth doing. Markdown is readable a year later, copyable across clients, and version controlled in git. A 60 column Clay table is none of those things.

If you have not seen what a real Yalc skill looks like, the leads qualification skill in the public repo is the canonical one. Read it before you write your first skill. It is short, opinionated, and shows you exactly the level of detail your migration needs to land at.

One skill per workflow. Name them the way you would name a Slack channel for that workflow. Future you will thank present you when you grep through ten skills to find the one that handles the new logo signal play.

Provider mapping: Clay enrichment chain to FullEnrich plus Crustdata

Clay's superpower was always the waterfall: try provider A, fall back to provider B, fall back to provider C, accept the first verified hit. The migration question is how to keep that waterfall when you leave Clay.

The answer for almost every team we have moved is a two provider stack. Crustdata for the people and company layer, including signals and firmographics. FullEnrich for the email and phone waterfall, which already runs its own internal multi provider chain so you do not have to wire one yourself.

The migration looks like this in practice. Anywhere your Clay table called find_email or find_phone with a stack of providers, replace it with a single FullEnrich call from your Yalc skill. Anywhere your table called enrich_company, enrich_person, or pulled hiring or funding signals, replace it with a Crustdata call. The skill body lists which fields you want, the provider returns them, your skill writes them into the output.

The gotcha here is consent timing. If you ran Clay with provider keys saved inside the workspace, those credits keep burning until you remove the keys. Pull the keys out of Clay on the day you start the parallel run, not the day you finish the migration. We learned that one the expensive way.

If you want a longer read on why an API first, markdown configured stack outperforms a vendor canvas at scale, the case sits in our writeup of the open source Clay alternative. It is the philosophical companion to this operational guide.

Sequencer mapping: Clay outreach to Instantly or Unipile

Most Clay workspaces push to a sequencer at the bottom of the table. Some hit a webhook into a custom Lambda. Some write a row to Google Sheets that then triggers a Zap. The migration target is simpler. One channel, one provider, one Yalc skill that handles the handoff.

For cold email, push to Instantly. The Yalc skill writes the CSV with the columns Instantly expects (email, first_name, company, custom_var_1 through custom_var_20) and either uploads via the Instantly API or drops the file into a watched folder. Either pattern works. The API pattern is cleaner once you trust the skill.

For LinkedIn, push to Unipile. Same shape. Your skill assembles the prospect list, picks the right sender account, writes the message body with whatever personalization variables your prompt produced, and posts the campaign to Unipile. The replies come back through the same API, so a separate Yalc skill can classify them and write the result back to your CRM of choice.

The thing that surprises operators leaving Clay is how much of the integration glue disappears. In Clay you wired if Apollo returned a verified email, run this column, otherwise skip across five columns. In a Yalc skill you write that as a single sentence inside the markdown and the model handles the conditional. The logic gets shorter, not longer.

The deeper context for how the channel choice maps to the broader stack lives in our breakdown of the operator playbook for B2B lead generation. Read it if you are deciding between cold email volume and LinkedIn first outreach as your primary motion.

Run both in parallel for two weeks

Do not cut over on day one. Run Clay and Yalc against the same input list for two weeks. Same ICP, same volume, same sequencer destination. Two parallel paths writing to two staging tables. You read the outputs side by side every morning.

The point of the parallel run is not to validate that Yalc works. It will. The point is to validate that your Yalc skill captures every edge case your Clay table accumulated over a year. Clay tables grow weird columns. Edge cases get patched with a conditional on row 47. Whoever built the table probably does not work at your company anymore. The only way to surface those edge cases is to run the new skill on real data and read the diff.

We catch three to five real bugs per migration during the parallel run. Always. Sometimes a Crustdata field is named slightly differently than the Clay column you copied. Sometimes FullEnrich returns a personal email where Clay returned the work email. Sometimes the Yalc skill prompt is too aggressive and disqualifies prospects your Clay table would have kept. You fix those during the parallel window, not after the cutover.

Set a small batch size during this period. Two hundred prospects per day, not two thousand. You are looking for shape, not volume. Volume comes after the cutover.

Cutover day checklist

The cutover is boring on purpose. If it feels exciting, you skipped a step.

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

The afternoon checklist looks like this. Run the first real production batch through Yalc. Watch the campaign launch. Pull the first ten replies from Unipile and Instantly and confirm they classify into your inbox correctly. Check the CRM rows landed where the skill says they should. Send the team a short note on Slack saying the migration is live and where to file bugs.

Day two through day five, sit with the system. Do not start a new project. Pipeline migrations always surface a quiet failure on day three. Be there to fix it inside the same morning instead of finding it on the following Monday.

What stays in Clay (if anything)

Some teams will keep Clay around for a specific kind of work. That is fine. The pattern that has held across the migrations we have run is simple. Keep Clay for one off enrichment pulls and ad hoc experiments. Move every recurring playbook to Yalc.

The break point is recurrence. A one time enrichment of 2,000 founders for a specific event sponsorship is the kind of job Clay still does well. A daily ICP qualification routine that runs on every new domain that hits your site is not. The daily routine wants to be a markdown file your operator can read and edit. The one off pull can live in a table that gets archived next week.

Some teams keep nothing in Clay after the cutover. That is also fine. The decision is about your team's habits, not about Clay's capabilities. If nobody on your team will open a Clay table once a quarter, you are paying for muscle memory you do not have. Cancel it.

Cost comparison at month one and month six

Month one is the honest moment. You will still be paying Clay (your annual contract has not lapsed), Crustdata and FullEnrich are now both billing, and your operator hours are heavier than usual because the migration is fresh. Expect a temporary cost spike of 20 to 40 percent for the first thirty days. This is the price of running both stacks in parallel and is exactly the same shape as any tooling migration in any business.

Month six is the interesting moment. The Clay contract is gone. Per credit pricing has been replaced by per call API pricing that scales more predictably with usage. Crustdata and FullEnrich each have their own pricing model that is easier to forecast than Clay credits because the unit cost is per record, not per column run. Operator time is the line that compounds in your favor. The skills you wrote in month one are still running in month six, but you have edited maybe two of them. The other eight are working quietly.

The teams that get the biggest win are the ones who were already paying for Crustdata or FullEnrich on the side and using Clay to wire them together. For those teams the migration is a straight cost removal at the Clay line, with no new provider bill to absorb. The teams that got there from a pure Clay setup see a smaller dollar saving on month six and a much larger ergonomic win in workflow ownership and version control. Both are real. Pick the math that matters for your team and run it before the cutover so finance knows what to expect.

The closing rule

Migrating from Clay to Yalc is not a tooling swap, it is a workflow rewrite. The audit takes one afternoon. The skill mapping takes a week. The parallel run takes two weeks. The cutover is one boring morning. The compounding starts the week after, and it does not stop.

The rule we operate by is the same one we tell every client. Buy the tools that produce real data and real sends. Replace the integration glue with markdown skills you can read a year later. Keep humans on the first mile and the last mile. Let the operator OS run the middle mile. If you only do one thing this week, run the leads qualification skill on a small test list and feel what the workflow looks like before you write your first migration skill. That is the cleanest entry point to the migration from Clay to Yalc, and the rest follows from there.