Migrate Alteryx Workflows

PlaidCloud converts Alteryx workflows, analytic apps, and macros into Advanced workflows that can be reviewed, scheduled, parameterized, and run in PlaidCloud. The importer preserves the workflow graph, uploads referenced files to Document, creates macro workflows when needed, and maps tools to native workflow steps or managed job executors.

Use this guide when you are moving a single workflow, a group of related workflows, or a larger Alteryx portfolio into PlaidCloud.

Note

Converted workflows are designed to require very little manual effort. For production workflows, PlaidCloud validation gives teams a clear readiness record before scheduling regular runs.

What PlaidCloud Creates

PlaidCloud creates a runnable Advanced workflow from the Alteryx design:

• Workflow tools become PlaidCloud workflow steps with the original upstream and downstream relationships preserved.
• Alteryx macros become PlaidCloud macro workflows with explicit macro inputs and macro outputs.
• Analytic app questions become controlled workflow variables that users can set before a run.
• Input files, output files, spatial sidecars, images, PDFs, and generated artifacts are stored in Document at the path selected during import.
• Assisted Modeling (machine learning) pipelines become native ML Train and ML Score workflow steps.
• Advanced operations such as fuzzy matching, spatial processing, PDF extraction, OCR, NLP, and reporting run through PlaidCloud’s managed job executors when a native SQL or workflow operation is not the best fit.
• Comment boxes and Tool Containers arrive on the workflow canvas as notes, highlight boxes, and groups. They explain the converted workflow exactly as they explained the original, and they add no runtime work.
• Browse, layout, and other designer-only objects are retained where they help explain the converted workflow, but they do not add unnecessary runtime work.

Before You Start

Collect the workflow files and dependencies together before importing:

1. Include Alteryx workflow, app, and macro files: .yxmd, .yxwz, and .yxmc.
2. Include input data files such as CSV, Excel, Access, YXDB, XML, JSON, and database extracts.
3. Include spatial sidecar files together. For example, keep shapefile groups and MapInfo files in the same folder.
4. Include report assets such as images, PDFs, map layers, and templates.
5. Choose the PlaidCloud project where the converted workflows should be created.
6. Choose the Document account and folder where PlaidCloud should upload imported files.
7. Decide whether this migration requires structural validation only or output parity validation.

Import A Workflow

1. Open the target project in PlaidCloud.
2. Open Tools → Import Alteryx Workflow.
3. Choose the target project and select the .yxmd, .yxwz, or .yxmc file to import.
4. Optionally set workflow, step, and table name prefixes. Table names are already prefixed with the workflow’s own name — see Table Names in a Converted Workflow below.
5. Choose the Document account and folder where imported files should be stored.
6. Add any referenced files or folders that the workflow needs at runtime.
7. Start the import.
8. Review the conversion report shown when the import finishes.
9. Open the generated Advanced workflow.

When the import finishes, the import window replaces its form with a conversion report: a summary of how many steps mapped with high confidence and how many need review, and — when any step needs a look — a table of the lower-confidence or caveated steps listing each step’s name, operation, confidence, and notes. Use it to go straight to the steps worth checking before you run the workflow; each of those steps also carries the same confidence note in its step memo on the canvas.

PlaidCloud stores imported dependencies in the Document location selected during import. Converted steps then reference those Document paths, so the workflow can run repeatedly without relying on a desktop file system.

Table Names in a Converted Workflow

Each converted step writes its own table, named after the Alteryx tool it came from — tool_4_out for Tool 4. Alteryx numbers tools per file, so those names repeat across workflows, and a PlaidCloud project is a single table namespace. Every import therefore prefixes its tables with the workflow’s own name, giving 03_measure_the_quality_of_data_tool_4_out. That is what lets a whole folder of Alteryx workflows go into one project without them writing over each other’s results.

Two workflows with the same name

The workflow name is the only thing telling two imports apart. Two files with the same name — or names that differ only in punctuation or spacing, such as Sales Report and Sales-Report — still produce the same prefix, as does a file that carries no name at all. Set a table name prefix yourself when importing those, or import them into separate projects.

Those imports no longer overwrite one another: an import that asks for a table name the project already holds gets its own table, named with a -duplicate- suffix, and its steps use it. Each import keeps its own results, but the second one’s table names are harder to read — so a prefix of your own is still worth setting.

Importing the same workflow twice, which is what happens when a first import needs correcting, works the same way: the second import gets its own set of tables rather than writing over the first. Delete the earlier import’s workflow and tables once you are happy with the new one.

Set your own table name prefix during import to override the default, or set it to nothing to get the bare tool_4_out names back. Nothing depends on these names other than the converted steps themselves, so renaming a table afterwards means repointing the steps that read it.

Comments and Tool Containers on the Canvas

The notes and groups an Alteryx author drew around their work come across with it:

• A comment box carrying text becomes a note on the canvas, at the position and size it was drawn at.
• A comment box drawn as an empty outline around a set of tools becomes a highlight box, which is what it was doing in Alteryx.
• A comment box that displays a linked document keeps the link as its text.
• A Tool Container becomes a group holding the steps that were drawn inside it, keeping its caption, whether it was folded shut, and whether it was switched off. Nested containers come across as nested groups, and a step inside both belongs to both.

Move, edit, recolor, or delete any of them the same way you would one you drew yourself.

Two things behave differently from the original:

• A switched-off Tool Container’s tools are not imported at all. Alteryx does not run them either, so importing them would put steps in the workflow that never do anything. The container itself still comes across, as a highlight box carrying its caption, so you can see what was there. To bring its tools in, switch the container on in Alteryx and import again. (Importing over the API or from an AI agent also accepts an option to import a disabled container’s tools as ordinary, runnable steps — useful for sample workflows that ship everything switched off.)
• Box colors are not carried across. The canvas offers a fixed set of six colors, and Alteryx boxes are almost always white or grey, so every one of them would arrive the same shade. They come in with the canvas default instead; set the color you want from the right-click menu.

A workflow that is nothing but comments — a page of documentation with no tools on it — imports as a canvas carrying those comments, and says it converted to no runnable step. That is the honest result, not a failure: there was nothing to run.

Use The Converted Workflow

After import, use the workflow like any other PlaidCloud Advanced workflow:

1. Open the converted workflow canvas.
2. Review the generated steps and branches.
3. Set workflow variables for any converted app questions or runtime parameters.
4. Run the workflow.
5. Review run history, step outputs, readiness notes, and generated artifacts.
6. Schedule the workflow when it is ready for repeatable operation.

Converted macros are available as PlaidCloud macro workflows. A workflow that called an Alteryx macro will call the generated PlaidCloud macro through the macro step. Macro runs are isolated from one another, so concurrent workflow runs can safely use the same macro definition.

Validate The Conversion

PlaidCloud supports two practical validation levels.

Structural Validation

Structural validation confirms that the workflow was converted into a runnable PlaidCloud DAG:

• Every Alteryx tool has a PlaidCloud conversion route.
• Required macros were found or generated.
• Required input files were uploaded to Document.
• Macro inputs and macro outputs are connected.
• Workflow variables were created for user-controlled inputs.
• The generated workflow opens and can be run in PlaidCloud.

Structural validation is useful for migration readiness, inventory review, and early portfolio conversion.

Output Parity Validation

Output parity validation compares the PlaidCloud run against trusted Alteryx outputs:

• Output schemas match.
• Row counts match.
• Row values match.
• Row order is ignored unless the workflow explicitly depends on ordering.

For workflows that create reports, maps, PDFs, images, or model artifacts, validate the generated artifact or the data behind the artifact according to the way your team uses the output.

See Validate Converted Alteryx Workflows for a detailed validation checklist.

Machine Learning (Assisted Modeling) Conversions

Alteryx machine-learning pipelines built with the Machine Learning tool family convert to PlaidCloud’s native ML steps:

• A Classification or Regression tool, together with its upstream Assisted Modeling and Transformation stages and the downstream Fit tool, fuses into a single ML: Train Model step. The step carries the exact algorithm, target variable, feature columns, and hyperparameters from the Alteryx workflow, and writes the trained model as a one-row model table with the training metrics recorded in it.
• Each Predict tool becomes an ML: Score step reading the trained model table and its data input. The prediction column is named after the target variable with a _predicted suffix.
• XGBoost classifiers convert with an approximation note: the model trains as a scikit-learn gradient-boosted classifier, and any XGBoost-specific tree parameters with no equivalent are listed in the step’s mapping notes. Validate model metrics against the Alteryx run before relying on parity.
• An Assisted Modeling wizard whose model was chosen interactively (and never saved into the workflow file) cannot convert — the importer keeps a placeholder step whose notes record the recovered target variable so you can hand-build the ML Train step.
• A standalone one-hot-encoding stage is flagged in the conversion report. The fused ML Train step one-hot encodes categorical features internally, so the standalone stage usually needs no replacement.

Like every conversion, the fused steps carry their confidence and notes in the conversion report and on the canvas, so the pipelines worth double-checking are easy to find.

Review Conversion Coverage

The Alteryx Conversion Matrix lists each supported Alteryx object, its coverage level, and the PlaidCloud operation used during conversion.

Use the matrix to understand how the importer handles each tool family:

• Native DAG steps for common data preparation, joins, filters, formulas, sorting, unions, sampling, and reshaping.
• Macro steps for macro inputs, macro outputs, macro invocation, control parameters, and macro concurrency.
• Controlled workflow variables for analytic app questions such as check boxes, drop-downs, text boxes, radio buttons, folder pickers, and file pickers.
• Document-backed file operations for input, output, directory, and dynamic file behavior.
• Native ML Train and ML Score steps for Assisted Modeling machine-learning pipelines.
• Managed job executors for specialized spatial, fuzzy matching, PDF, OCR, NLP, reporting, and artifact work.
• Cloud-native equivalents where PlaidCloud creates a durable, shareable artifact rather than reproducing an Alteryx-specific desktop renderer or proprietary file format.

Recommended Migration Practice

For a large portfolio, migrate in batches:

1. Import the workflows and macros into a migration project.
2. Complete dependency packages before reviewing individual formulas or business logic.
3. Run structural validation across the batch.
4. Prioritize output parity validation for production workflows, regulatory workflows, and workflows with downstream consumers.
5. Promote validated workflows into the target production project.
6. Schedule production runs and monitor run history.

Related Guides

• Alteryx Migration Readiness Checklist
• Package Alteryx Dependencies
• Validate Converted Alteryx Workflows
• Use Converted Alteryx Apps
• Orchestrate Alteryx Migrations With MCP
• Tune Alteryx Imports
• Validate Alteryx Reports And Artifacts
• Migrate Spatial Alteryx Workflows
• Create A Macro
• Run A Workflow
• Manage Workflow Variables
• Alteryx Conversion Matrix

Migration Documentation Set

For larger migrations, use these focused guides with this migration guide:

• Alteryx Migration Readiness Checklist for migration planning and package review.
• Package Alteryx Dependencies for files, folders, macros, spatial sidecars, and expected outputs.
• Use Converted Alteryx Apps for controlled workflow variables and app-style runs.
• Orchestrate Alteryx Migrations With MCP for using an AI agent to organize files, work from connected shared storage, and coordinate many conversions through PlaidCloud’s MCP server.
• Tune Alteryx Imports for dependency completion, macro resolution, variables, validation comparisons, and executor readiness notes.
• Validate Alteryx Reports And Artifacts for PDFs, images, maps, charts, dashboards, and model artifacts.
• Migrate Spatial Alteryx Workflows for spatial files, SQL geometry logic, managed spatial executors, and spatial validation.