# Migrating to Glow

> Plan, rebuild, test and cut over an automation from another platform without carrying across the wrong assumptions.

Use this checklist to move an existing automation into Glow, validate its behavior and switch it over safely. Import is available for n8n and Make; migrations from other platforms start with the same plan but use a manual rebuild.

## Migration Checklist

### 1. Record the current behavior

Before changing tools, capture what the automation must preserve:

- how it starts, including schedules, webhook callers and app triggers;
- the app accounts and permissions it uses;
- its branches, loops, delays and failure paths;
- custom code or platform-specific steps;
- representative inputs, expected outputs and external side effects.

This becomes the acceptance checklist for the Glow version. Focus on behavior rather than reproducing the old canvas step for step.

### 2. Choose the migration route

- **From n8n or Make:** follow [Importing a Workflow](/getting-started/templates/import-and-export) for the supported file format, import procedure and what requires attention afterward.
- **From another platform:** rebuild from the outcome backward. [Choose the Right Step](/build/which-step) maps common workflow shapes and goals to Glow Steps.

Treat an imported workflow as a starting point. Review it with the same care as a manual rebuild.

### 3. Complete the Glow workflow

- Reconnect every app account used by the workflow.
- Open each Step and confirm its operation, fields and mapped data.
- Replace custom code and platform-specific actions with the appropriate Glow Steps.
- Rebuild routing and repeated work using the patterns in [Choose the Right Step](/build/which-step).
- Review retry and failure settings for Steps that call external services.

### 4. Test against known cases

Run representative inputs through the Glow workflow and compare the results with your acceptance checklist. Include every route, empty or missing values, lists with more than one item and a controlled failure.

Use test destinations where a run sends messages, creates records or changes external data. Inspect the output of each Step before testing the workflow end to end.

### 5. Cut over

1. Keep the original automation available while you validate the Glow version.
2. Switch the Glow workflow to **Live** only when its trigger, connections and outputs are ready.
3. Confirm a real run completes as expected.
4. Disable the original automation so both platforms cannot process the same event.
5. Review the first live runs and keep the previous configuration available until the migration is accepted.

## Platform Differences

| Area                   | What changes in Glow                                                                                        | What to do during migration                                                                                                                                                         |
| ---------------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Terminology            | Familiar concepts may use different names, including **Step**, **Workflow Assistant** and **App drawer**.   | Use the [Glossary](/reference/glossary) instead of translating terms from memory.                                                                                                   |
| Workflow shape         | Routing and repeated work may need a different canvas structure rather than a one-to-one Step replacement.  | Start with the patterns and decision tables in [Choose the Right Step](/build/which-step).                                                                                          |
| Data mapping           | Fields can include data selected from earlier Steps alongside typed text.                                   | Reinsert each dynamic value and inspect the producing Step's output rather than copying expressions from the old platform. See [Workflow Data](/build/core-concepts/workflow-data). |
| Testing and activation | You can test while the workflow is in **Draft**. Switching it to **Live** activates its configured trigger. | Test with controlled inputs and destinations before the cutover. See [Operating Workflows](/build/core-concepts/operating-workflows).                                               |
| Failure handling       | Retry and failure behavior is configured on the Step.                                                       | Review these settings explicitly instead of assuming the previous platform's policy carries over. See [Error Handling & Retries](/build/core-concepts/error-handling).              |

## What's Next?

- 👉 **[Import Your Workflow →](/getting-started/templates/import-and-export)**
- Rebuilding from another platform? Start with [Choose the Right Step](/build/which-step).
- Need to translate a product term? Keep the [Glossary](/reference/glossary) open.