Migrate from Make to Activepieces

Migrating from Make to Activepieces: what the move involves

Migration means rebuilding each Make scenario as an Activepieces flow in your own environment, then recreating every app connection, because a Make scenario does not carry its credentials with it. Teams usually arrive here for one of three reasons: a renewal that brings a higher credit spend, credit consumption that grows faster than the team expects, or a requirement that the automation runtime sit inside the organization's own network. Whichever drives the decision, the work is the same: inventory the scenarios, decide which ones move first, rebuild them, and cut over without losing triggers or breaking downstream systems. Start by exporting each scenario as a blueprint .json file from Make. The blueprint holds the modules, module settings and mapped values, which gives the rebuild team a precise record of what each scenario does. It does not hold connections, so every account credential must be re-authorized in Activepieces.

The work usually falls to the internal platform or integration team, since they own the systems the scenarios touch and understand the business logic behind them. Some organizations bring in an outside implementation partner for the first wave, especially when scenarios depend on private systems, custom code or strict change control. Effort depends mainly on how many scenarios exist, how many distinct apps they use, and how much of the logic depends on Make-specific constructs such as routers, iterators and aggregators, which need to be re-expressed in Activepieces flow steps. Confirm first whether each app your scenarios call has an Activepieces piece, because the repository lists more than 280 pieces. For any app without one, plan a custom piece as a separate work item with its own testing. The main risks are silent behavior changes in mapped data, credentials that expire or lack the right scopes, and scenarios that run on a schedule and are switched off in Make before the replacement is verified.

Plan the cutover one scenario at a time. Run the rebuilt flow beside the Make original against test data, compare outputs, then disable the Make scenario and confirm the Activepieces flow is turned on and receiving events. Keep the Make blueprints as a rollback reference until the last scenario is verified. Before you commit, confirm with Activepieces which edition your self-hosted deployment will use, since the community edition is MIT licensed while the features in packages under ee carry a commercial license. Check the Activepieces pricing page for which governance features, such as SSO, audit logs and SCIM, belong to which tier, and ask any implementation partner for a written scope that lists the scenarios, the pieces, the custom work and the acceptance tests before work starts.

Which Make capabilities map to Activepieces, and what needs rework

This table compares the main Make building blocks with their Activepieces equivalents and marks each row as clean, needs rework or gap. Use it to scope the rebuild before you inventory apps, because piece coverage must be checked against your own list of applications rather than assumed. The main takeaway is that most flow logic maps directly, while app coverage, error handling details and paid-tier governance features need confirmation.

Make capability	Activepieces equivalent	Status and what to confirm
Scenarios and blueprint export	Flows built from pieces and steps	Needs rework. Blueprint JSON is not a native import format, so plan to rebuild each scenario manually and retest it.
Modules for named apps	Pieces (integrations), 280+ listed in the repository	Needs rework. Confirm each app in your inventory has a piece with the actions and triggers you use.
Routers and filters	Branch steps with conditions	Clean for simple conditions. Re-check nested routers and fallback paths during testing.
Iterators and aggregators	Loop steps and data transforms in code or built-in steps	Needs rework. Batch sizes, output shape and ordering must be verified against the original scenario.
Error handlers and retries	Error handling settings per step and flow-level behavior	Needs rework. Map each Make error route to an explicit Activepieces path and confirm retry behavior on your version.
Data mapping and expressions	Mapping from prior step outputs	Needs rework. Mapped values are not carried over, so re-enter and test every field reference.
Schedules and webhooks	Schedule and webhook triggers	Clean for standard triggers. Confirm endpoint URLs and polling intervals in your own environment.
Custom apps with no existing module	Custom pieces built in TypeScript	Gap until built. Budget engineering time for each missing app and plan maintenance of the piece.
SSO, audit logs and SCIM	Available on paid Team or Ultimate tiers per the pricing page; the MIT Community edition is the automation core	Gap on Community edition. Confirm which tier you need before you commit to a self-hosted design.

What moves from Make and what must be recreated

A Make blueprint carries the structure of a scenario but not the credentials that make it run. The cards below separate what the export gives you from what your team must rebuild, document and test before switching off Make.

Scenario structure from the blueprint

A blueprint .json file holds the scenario's modules, module settings and mapped values. That is the logical design you can reuse as a reference when rebuilding each scenario as an Activepieces flow. Open each exported file and confirm that every module, filter and mapping appears before you start the rebuild. Treat the blueprint as a specification, not an import that runs unchanged in Activepieces.

Connections must be recreated

Connections are not included in a blueprint. Every app login, API key and OAuth grant has to be created again in Activepieces under the account or service identity that will own the flow. Record which Make connection each module used, the account it authenticated as and the scopes it held. Confirm with your identity owners that the replacement credentials have the same or narrower permissions than the originals.

Inventory of scenarios and credentials

Before rebuilding, list every active scenario, its owner, its trigger, the apps it touches and the data classes it handles. Include scenarios owned by people who have left, because they often hold the only copy of a credential. Export blueprints for all of them and store the files under change control. Ask Make which export paths your plan supports, since the scenario list in your account is the source of truth for scope.

Webhooks and schedules to re-register

Triggers do not move with the scenario. Each webhook URL that external systems call must be re-pointed to the new Activepieces trigger, and each scheduled run must be recreated with the same timing and time zone. For each one, note the upstream sender, the expected payload and the cutover window. Run both systems in parallel for a short period where duplicate actions are safe, and confirm that no event is processed twice.

Apps without a matching piece

Activepieces ships more than 280 pieces, but some Make apps or modules will have no matching piece. Map each module to a piece, then flag the gaps. For a gap, you can call the vendor's HTTP API through a generic step, or build a custom piece in TypeScript. Confirm each mapping against the current piece catalog in the repository, because coverage changes between releases.

Custom pieces and their upkeep

A custom piece is code your team owns. It needs its own version control, tests, secrets handling and a plan for when the upstream API changes. Assign an owner for each custom piece and document its authentication method and rate limits. Ask Activepieces how custom pieces are packaged and deployed in your self-hosted install, and confirm that the process fits your change management rules.

The migration sequence from inventory to decommission

This sequence moves Make scenarios into self-hosted Activepieces in controlled stages, so each scenario is inventoried, rebuilt, compared against its Make output and retired only after its behavior is confirmed. The output is a set of tested flows, a cutover record and a retained archive of the original Make exports.

Build the scenario inventory register
List every active and paused Make scenario in each team account, with its trigger, modules, schedule, data stores, owner and the systems it writes to. Mark which scenarios run on a schedule, which respond to webhooks and which depend on a private system that a cloud service cannot reach. The inventory register is complete when every scenario has an owner, a business purpose and a risk rating agreed by the team that depends on it.
Export blueprints and record connections
Export each scenario as a blueprint .json file from Make, then store the files in version control or an access-controlled archive. A blueprint holds modules, module settings and mapped values, but not connections or credentials, so record which app account each connection uses and who can reauthorize it. Check each Activepieces piece in the Activepieces catalog against the modules in the inventory and note gaps. This step is done when every blueprint is archived and every module has either a matching piece or a planned custom piece.
Install the self-hosted Activepieces environment
Deploy the Community edition in your own environment using the Docker Compose or Helm chart path described in the Activepieces installation documentation, with PostgreSQL and Redis as the documented dependencies. Confirm the edition you are running, because community-maintained hosting templates usually ship the Community edition, and check whether any feature you rely on, such as SSO or audit logs, requires a paid tier. The environment is ready when a test flow runs end to end and a backup of the database has been restored successfully on a separate host.
Pilot rebuild of one low-risk scenario
Choose one scenario with a small blast radius, such as a scheduled report or an internal notification, and rebuild it as an Activepieces flow using the blueprint as the specification. Map each router to conditional branches, each iterator to a loop and each aggregator to a step that collects results, and document every place where the translation required a judgment call. Reauthorize the connections in the new environment rather than copying anything from Make. The pilot is complete when the flow passes its test runs and the rebuild notes explain each deviation from the original.
Build custom pieces for missing integrations
For each inventory item without a matching piece, decide whether a generic HTTP step, a webhook or a custom piece is the better fit. Where a custom piece is needed, develop it against the app's documented API, keep its credentials in the platform's connection store and test it against a sandbox account before any production use. Record the owner, the API version it targets and the review date for each custom piece in a register. Confirm the licensing position for any third-party code you bring in, since the repository applies a separate commercial license to content under packages/ee.
Run parallel comparison of outputs
Run the rebuilt flow alongside the original Make scenario against the same inputs, with writes to production systems disabled or redirected to a staging target. Compare record counts, field values, timestamps, error paths and notifications in a comparison log, and investigate every mismatch before proceeding. The step closes when the log shows matching results for the agreed test window and each scenario owner has signed off the differences that remain.
Cut over triggers and connections
Write a cutover runbook for each scenario that lists the order of operations: pause the Make scenario, disable its trigger, enable the Activepieces flow and confirm the first live run. Include the rollback steps, such as re-enabling the Make scenario, and name the person who can authorize each action. Move webhooks and schedules in the same window so no event is processed twice or dropped. The cutover is complete when the runbook is signed off and the first live runs for each scenario are confirmed in the Activepieces run history.
Decommission Make scenarios and retain exports
After the stabilization period agreed by the owners, deactivate the Make scenarios and remove stored credentials from Make connections. Keep the final blueprint exports, inventory register, comparison logs and runbooks in your own retained archive, with a record of who approved each decommission. Confirm with your contract or billing team what happens to your Make account and data, since retention terms belong to the vendor agreement. The decommission record is complete when every scenario in the inventory has a status of retired, archived or intentionally kept.

What drives the cost and duration of the rebuild

This table lists the main factors that move the cost and length of moving Make scenarios to self-hosted Activepieces, with why each one matters and how to keep it under control. Use it to read a written quote line by line and to ask the right questions before work starts.

Driver	Why it changes cost or effort	How to keep it down
Number and complexity of scenarios	Each scenario is rebuilt by hand, so the count and size of scenarios set most of the labor. Blueprint exports show module counts but not how the logic behaves in production.	Rank scenarios by business value and run volume, retire unused ones first, and ask for a scenario inventory in the quote.
Piece coverage for Make modules	Activepieces lists more than 280 pieces, but not every Make module has a matching piece. Each gap adds build work or a manual HTTP step.	Map every module in each blueprint to a piece before estimating. Ask the vendor to confirm the exact piece and action names you need.
Custom pieces for missing apps	Writing and testing a custom piece is a development task with its own review, versioning and maintenance after handover.	Limit custom pieces to apps with real demand, reuse existing HTTP patterns, and ask who owns the code and updates after go-live.
Branching, loops and error handling	Make routers, iterators, aggregators and error routes must be re-expressed in Activepieces flow logic. Edge cases such as partial failures take the longest to verify.	Simplify logic during the rebuild rather than copying every route, and write down expected behavior for each error path.
Data mapping complexity	Mapped values that reference nested outputs or custom functions need checking field by field against sample data.	Test with representative records from production, and keep a mapping sheet that the reviewer can sign off.
Connections and credentials	Make connections are not carried in blueprints, so every app connection must be recreated and tested in the new environment.	Inventory all connections early, assign owners for each credential, and ask whether the quote includes secret handling.
Hosting, Docker Compose or Helm setup	Self-hosting with Docker Compose or the Helm chart for Kubernetes requires network, TLS, storage and upgrade planning inside your environment.	Confirm the target platform first, then decide on Compose or Helm. Ask for the install, backup and upgrade steps in writing.
PostgreSQL and Redis operations	Activepieces recommends PostgreSQL and Redis. Running, backing up and patching these services becomes a recurring operations task.	Decide whether to use managed services already approved in your environment, and ask what backup and restore testing is included.
Testing and parallel run length	Running old and new automations side by side protects revenue and data, but it extends the project and doubles some monitoring work.	Prioritize high-risk scenarios for parallel runs and agree exit criteria in writing before cutover.
Paid tier for SSO or audit logs	Activepieces lists SSO from the Team plan, and audit logs, Git sync, SCIM and external secret managers only on Ultimate. Adding these changes licensing and integration work.	Confirm which controls you require before design. Check the current pricing page, since tier contents can change, and ask for licensing in the quote.

How the migration differs by starting point

A team with a handful of scenarios on Make's cloud usually has the simplest path. The work is mostly rebuilding a few flows, recreating connections and turning on a single self-hosted Activepieces instance, often with Docker Compose and PostgreSQL and Redis as the documented base. The main effort is deciding which scenarios are worth rebuilding and which should be retired.

Sequence emphasis: Inventory scenarios first, then rebuild the most used ones before retiring any Make scenario.
Hosting work: One node running the Docker Compose setup, plus backups of PostgreSQL and a plan for upgrades.
Connection recreation: Blueprint exports do not carry connections, so each app login must be re-authorized in Activepieces.
Integration gaps: Check each module against the pieces list, since some Make modules may have no matching piece and need a custom piece.
Community edition scope: Confirm which features your team needs, such as SSO or audit logs, and whether the MIT Community edition covers them.

Before cutover, run each rebuilt flow against test data and confirm that every connection and trigger works as the Make scenario did.

What usually goes wrong and how to prevent it

Most failed Make to Activepieces migrations break at the seams: connections, data handling, and the unowned parts of the new setup. The cards below cover the failure points that recur, with a prevention step for each so the cutover is checked before anything goes live.

Missed connections and credentials

A Make blueprint carries the modules, settings and mapped values, but not connections or credentials. Every app login, API key and OAuth grant has to be recreated in Activepieces, often by a different account owner than the one who built the scenario. Scenarios can import cleanly and still fail on the first run. Build an inventory of every connection each scenario uses, assign an owner for each, and test each one before enabling the flow.

Silent differences in mapping and errors

Make and Activepieces may handle empty fields, data types, array indexing and error routing differently, so a flow can run without errors yet produce different output. Failures that Make surfaced through its error handlers may be swallowed or retried differently. Compare outputs of the old and new flows on the same sample records, field by field, including the edge cases of empty and malformed input. Confirm retry and error behavior in the Activepieces documentation for each step type you use.

Duplicate triggers during parallel run

Running the Make scenario and the Activepieces flow side by side is the safest cutover, but both can react to the same new record, email or webhook. The result is duplicate tickets, double invoices or repeated messages to customers. Before going live, disable the trigger on one side or split the source by filter, and record which system owns each event type for the parallel period. Keep a written cutover date so the old scenario is switched off on schedule.

Apps without a piece

Activepieces lists more than 280 pieces, but a Make scenario may depend on a module for an app that has no piece, or on a generic HTTP call that the team assumed was covered. The gap often appears only in the last scenario being rebuilt. Map each Make module to a matching Activepieces piece before scoping the work, and mark any app without one as a custom piece or an HTTP step to be reviewed by the owner. Confirm the current piece list in the repository, since it changes between releases.

Custom pieces without maintainers

A custom piece built to replace a missing integration becomes production code. When the external API changes, the piece breaks, and if nobody owns it, the flows that depend on it stop without warning. Custom pieces also need credentials handling, version control and review like any other service. Name a maintainer for each custom piece, store its code in your own version control, and set a review date tied to the upstream API's change log.

Community edition expectations

The Community edition is MIT licensed and is the automation core on its own, but SSO, audit logs, Git sync, SCIM and external secret managers are listed on the pricing page only for higher tiers. Teams that assumed these were included may discover gaps during an access review. Community-maintained hosting templates usually ship the Community edition too. Before cutover, list the controls your auditors and identity team require, check each against the pricing page, and decide whether to build them, buy them or accept the gap in writing.

Questions teams ask before moving from Make to Activepieces

How much effort does a Make to Activepieces migration take?

Effort depends mostly on how many scenarios you run, how many modules each one uses and how many of those modules have a matching Activepieces piece. A scenario with a few triggers and common SaaS actions is a short rebuild. A scenario with nested routers, iterators, aggregators, error handlers and custom HTTP calls takes longer to rebuild and to test. The cost has two parts: the internal or partner time to rebuild and test flows, and the operations work to host and monitor the new runtime. Ask any implementation partner for a written scope that lists each scenario, its modules and the pieces or custom work it needs.

How long does a migration from Make to Activepieces take?

The timeline is set by the number of scenarios, their dependencies on other systems, the test and sign-off process, and how many custom pieces you must build. Scenarios that feed billing, identity or customer records usually need parallel running and reconciliation before you switch off the Make version, which extends the schedule. Start with an inventory of active scenarios and their run frequency, then sequence the rebuild by business risk. Confirm durations with your partner or internal team against that inventory rather than against a generic estimate.

What does the team need to supply for the rebuild?

The team needs to supply the scenario inventory, access to every source and target application with credentials or service accounts that can be created, and named owners who can approve test results. You also need a hosting target that meets your network and data residency rules, such as a Docker Compose or Kubernetes environment with PostgreSQL and Redis, as described in the Activepieces installation documentation. Connections are not carried over from Make, so each app connection must be recreated and tested. Plan for a staging environment with non-production data so that each rebuilt flow can be checked before cutover.

Can our own engineers do the migration without a partner?

Yes, a team with workflow and API experience can rebuild simple scenarios in-house, especially if they start with the most common pieces. The work becomes harder when scenarios use complex data mapping, custom HTTP calls, error routing or systems that have no matching piece, because those need TypeScript-based custom pieces and more testing. Consider the operations side too: someone must own upgrades, backups, monitoring and access control after go-live. Many teams split the work, keeping routine flows in-house and bringing in outside help for custom pieces, security review or hardening.

Does a Make blueprint import into Activepieces?

No, you should not expect a blueprint to import as a working Activepieces flow. Make exports a scenario as a blueprint .json file that holds modules, module settings and mapped values, but Make's help center notes that connections are excluded and must be recreated after import. That file is a reference for planning the rebuild, not a conversion format for another product. Use it to list modules, filters, routers and mappings, then rebuild each step in Activepieces and test it against the same sample data. Confirm current import behavior with Activepieces before relying on any tooling.

What does the Activepieces license mean for self-hosting?

The Activepieces community edition is MIT licensed, which permits self-hosting for internal use and modification under the license terms. The exception is content under the enterprise directories, which sits under a separate commercial license. The LICENSE file in the repository sets out those boundaries, so check it with your legal team before you deploy. Community-maintained hosting templates usually ship the Community edition, so confirm which edition your chosen image contains. Features such as SSO, audit logs and SCIM are tied to paid tiers on the Activepieces pricing page, so list the controls you need before you choose an edition.

Which Make features may not have a direct Activepieces equivalent?

Some Make features need a design decision rather than a one-to-one mapping. Scenario-level features such as specific error handler routes, data stores and some scheduling options should be checked against the current Activepieces docs before you commit to a design. Apps without a matching piece need a custom piece or an HTTP step, and the Activepieces repository notes that most pieces are community-contributed, so you should review and test any community piece before use. Document each gap as a separate work item so that it is priced and tested on its own.

What should we check before the first production cutover?

Before cutover, confirm that every rebuilt flow produces the same outputs as the Make version on the same test inputs, that each connection uses a dedicated service account, and that secrets are stored outside flow definitions. Verify backup and restore of the PostgreSQL database, the update process for the chosen release, and alerting for failed runs. Run both versions in parallel for an agreed period, reconcile results, and keep the Make scenario disabled but not deleted until the rollback plan has been tested.

Where DeployOpen fits in a Make to Activepieces move

DeployOpen plans, implements, integrates, hardens, backs up and documents a self-hosted Activepieces deployment inside your own cloud account, data center or air-gapped network. For a Make migration, that means the Activepieces server, its PostgreSQL and Redis dependencies, the connection to your internal systems, the secrets handling for app credentials, and the backup and upgrade routine that your operations team will run after handover. Make's blueprint export does not carry connections, so every credential has to be recreated in the new environment, and that step is usually where a migration plan needs the most care. DeployOpen can take on the installation and integration work, but your team still decides which systems get connected, who holds each credential and which scenarios go live first. DeployOpen also prepares systems, controls and evidence for compliance assessments, such as access records, configuration baselines and backup test results. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so ask your assessor early which evidence they expect from an automation platform that now holds your application credentials. Activepieces' own pricing page places SSO, audit logs, Git sync, SCIM and external secret managers in its Ultimate tier, and the Community edition is MIT licensed. Confirm with Activepieces which of those controls your assessment needs before you choose the edition that your evidence depends on. Most DeployOpen engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope. To get a useful quote, prepare an inventory of the Make scenarios in use, exported as blueprint JSON files, along with the apps and internal systems each one touches, the hosting location you require and the compliance controls you must evidence. Ongoing support, upgrades and continuous testing are available as separate retainers, so ask for those to be quoted apart from the one-time migration work.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Make to Activepieces, the work starts with a written scope, moves through rebuilding and testing flows, and ends with documentation, handover and optional ongoing support.

How we scope

Inventory every Make scenario, including its triggers, routers, iterators and error handlers, before agreeing what moves.
Confirm which apps each scenario uses and whether an Activepieces piece exists or a custom piece must be written.
Agree deliverables, timelines and acceptance tests in writing before any rebuild work begins, as engagements are fixed-scope.

How we build

Deploy the self-hosted Activepieces stack in your environment, using the Docker Compose or Helm options your team selects.
Rebuild scenarios as flows, recreate connections with credentials held in your own secret store, and test each flow against live data.
Write custom pieces for apps without an existing piece, and review them against your security standards before release.

How we hand over

Document each rebuilt flow, its owner, its connections and the test results that show it matches the original Make scenario.
Run a cutover plan that turns flows on in a controlled order and keeps the Make scenarios available until results are confirmed.
Train your operations staff on running, updating and troubleshooting the platform, and deliver the runbook as part of the handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately from the migration.
Confirm with Activepieces which edition covers your needs, since SSO, audit logs, Git sync and SCIM are listed on different paid tiers.
Ask for the support scope, response expectations and upgrade approach in your written quote so the terms are clear before work starts.