Skip to content
PlaidCloud

Migrate Your First Alteryx Workflow

~30 minutes · a readiness check, an import, a validated run

Move one Alteryx workflow into PlaidCloud end to end: check that it’s ready, import and convert it, read what converted cleanly versus what needs a look, and run it. This is a first migration meant to build confidence — not an exhaustive tour. Pick a workflow you understand well and, ideally, one you have a known-good output for, so you can tell the converted run is right.

PlaidCloud’s importer preserves the workflow graph, uploads referenced files to Document, generates macro workflows, and maps each Alteryx tool to a native workflow step or a managed executor. Most of a workflow converts with little manual effort — and the honest part of this tutorial is the rest: some tools need attention, and PlaidCloud tells you exactly which ones so you can go straight to them.

1 · Check readiness2 · Import + convert3 · Review + validatewhat converted vs. flagged4 · Run
The whole migration in four phases. The review phase is where you spend your judgment.

Prerequisites

Section titled “Prerequisites”
  • A PlaidCloud workspace and a project to import into. Use a dedicated migration project so dependencies stay easy to audit.
  • One Alteryx workflow file — .yxmd (workflow), .yxwz (analytic app), or .yxmc (macro).
  • The files that workflow reads at runtime, kept together with it.
  • A Document account and folder where PlaidCloud can store the imported files.

Step 1: Check Readiness

Section titled “Step 1: Check Readiness”

A clean import starts with a complete package. Gather everything the workflow touches before you open the importer:

  1. The workflow file itself, plus any macros it calls — including nested macros — as .yxmc files.
  2. Input data files: CSV, TSV, Excel, Access, YXDB, XML, JSON, and database extracts.
  3. Spatial sidecars kept in the same folder — shapefile groups (.shp, .shx, .dbf, .prj), MapInfo groups (.tab, .map, .id, .dat), and any projection files. Missing sidecars are a common source of spatial differences.
  4. Report assets the workflow references: images, PDFs, templates, and map layers.
  5. For an analytic app, the values users normally enter — text, numbers, dates, file and folder picks, and drop-down or checkbox selections. These become workflow variables you’ll set before a run.

Then decide two things: the Document folder that will hold the uploaded files, and whether you’ll validate this workflow structurally (does it convert and run?) or against known-good outputs (does it produce the same results?).

Bring the known-good output. If you have a trusted result from the Alteryx run, keep it with the package. It’s what turns “it ran” into “it’s correct” in Step 4.

The Alteryx Migration Readiness Checklist is the full version of this step for when you graduate from one workflow to a portfolio.

Step 2: Import and Convert

Section titled “Step 2: Import and Convert”
  1. Open your target project in PlaidCloud.
  2. Open Tools → Import Alteryx Workflow.
  3. Choose the target project and select your .yxmd, .yxwz, or .yxmc file.
  4. Optionally set workflow, step, and table name prefixes. Table names are already prefixed with the workflow’s own name, so a single workflow needs no prefix of its own.
  5. Choose the Document account and folder for the imported files.
  6. Add any referenced files or folders the workflow needs at runtime.
  7. Start the import.

When the import finishes, the window replaces its form with a conversion report: how many steps mapped with high confidence, how many need review, and — when any do — a table naming each lower-confidence step, its operation, its confidence, and notes. This report is the heart of the migration. Every flagged step also carries the same note in its step memo on the canvas, so you can jump straight to it.

PlaidCloud stores the imported dependencies in the Document folder you chose and points the converted steps at those paths, so the workflow runs repeatably without a desktop file system.

Comments and containers come along. Comment boxes arrive as notes and highlight boxes, and Tool Containers become groups — they explain the workflow exactly as they did in Alteryx and add no runtime work. A Control Container’s gate is preserved too: its steps are imported already set to run only when the gated data has rows.

Step 3: Review What Converted vs. What Needs Attention

Section titled “Step 3: Review What Converted vs. What Needs Attention”

Open the generated Advanced workflow and work the conversion report top to bottom. Most steps convert with high confidence and need nothing from you. The flagged ones are where a first migration earns its trust — read each note and decide.

Here’s the honest shape of partial conversion, and what each case means:

What you see What it means What to do
High-confidence step Mapped cleanly to a native step or executor Nothing — spot-check if you like
Step flagged for review Converted, but with a caveat worth confirming Read the note; verify the result against expectations
Step marked not converted The importer refused rather than guess wrong Fix the cause in Alteryx and re-import, or hand-build the step
A reference to a table that doesn’t exist yet A Calgary or externally-built dataset the workflow didn’t create Load the named table before running

A few flags you’re likely to meet on a first migration:

  • Random sampling (Create Samples, Random % Sample) carries over sizes and proportions exactly, but PlaidCloud draws its own records — validate these on counts and proportions, not on which rows landed where.
  • XGBoost models convert as a scikit-learn gradient-boosted classifier; expect statistical equivalence, not identical values, and check the step’s notes.
  • A not-converted step fails on purpose when the workflow reaches it, so a conversion with an unresolved gate or a missing table can’t be run through as if nothing were wrong. That candor is deliberate — it’s the importer refusing to report a wrong number as a right one.

A green run isn’t automatically a correct one. The report tells you where to look; validation in the next step tells you whether to trust the numbers. Don’t skip it on a workflow whose output someone depends on.

For the full catalog of how each tool family converts, see the Alteryx Conversion Matrix.

Step 4: Set Variables, Run, and Validate

Section titled “Step 4: Set Variables, Run, and Validate”
  1. On the converted workflow canvas, review the generated steps and branches.
  2. Set any workflow variables — these are your converted app questions and runtime parameters. Point file and folder variables at the Document paths from Step 2, and match the values you used in the Alteryx run.
  3. Click Run on the workflow (not a single step) and watch the log as each step executes in order.
  4. Review run history, step outputs, and any readiness notes.

Then validate at the level you chose in Step 1:

  • Structural — the workflow opened, the graph has the expected branches and macros, inputs uploaded, variables appeared, and the run completed. Enough for readiness and inventory.
  • Output parity — compare schema, row count, and row values against your trusted Alteryx output. Row order is ignored unless the workflow explicitly sorts. Also check null handling, numeric precision, dates, and geometry where they apply.

If a comparison differs, work the causes in order: missing or different input files, different variable values, different source snapshots, then null/date/rounding/collation differences, then spatial reference or geometry format. Correct the cause, rerun, and compare again. The validation guide has the full checklist.

Re-importing is safe. Fixing a package and importing again gets its own set of tables rather than overwriting the first import — delete the earlier workflow and its tables once you’re happy with the new one.

You’ve Migrated a Workflow

Section titled “You’ve Migrated a Workflow”

You took one Alteryx workflow from a readiness check to a validated PlaidCloud run, and — just as important — you can now read the conversion report to tell what converted cleanly from what needs a look. That’s the whole loop. Repeat it per workflow, and for a larger portfolio, migrate in batches into a dedicated project.

Where to Go Next

Section titled “Where to Go Next”