Enterprise customers can use their own SSO implementation, so access to the new platform follows your identity rules from the first day.
Source: make.com/security
From Workfront Fusion to MakeMigrate from Adobe Workfront Fusion to Make
Adobe Workfront Fusion was built on Make's automation engine, so its scenarios, modules, routers and filters work the way Make's do. Moving to Make keeps that way of building and opens it to every team, not only Workfront users.
Why teams move from Workfront Fusion to Make
Beyond Workfront: Fusion is sold with Adobe Workfront; Make is a platform for every team's automation, with Workfront as one of its apps.
Make's own apps and features: Make ships new apps and features on its own platform, while Fusion's app list is Adobe's decision and can differ.
Keep Workfront: Make has an Adobe Workfront app, so your Workfront automations keep running after the move.
Enterprise controls: your own single sign-on, teams and roles, longer log storage and support terms on Make Enterprise, as Make lists them.
Workfront Fusion concepts in Make
What each part of a Workfront Fusion workflow becomes when it is rebuilt as a Make scenario.
| In Workfront Fusion | In Make |
|---|---|
| Fusion scenario | Make scenario (the same concept) |
| Modules | Modules (the same concept; versions can differ) |
| Routers, filters, iterators and aggregators | The same tools in Make |
| Workfront modules | Make's Adobe Workfront app, or HTTP calls to the Workfront API for anything it does not cover |
| Connections | Make connections, re-authorised by the account owner |
| Data stores and data structures | Data stores and data structures, re-created in Make with their records moved |
| Scenario blueprints | Blueprint import into Make as a starting point, then tested |
| Error handlers | The same error handler routes in Make |
| Operations | Operations (billed in credits) |
| Fusion organization and teams | Make organization, teams and roles |
This is the closest of these moves to one-to-one, but it is not a copy and paste. Fusion's app modules, module versions, connections and licensing are Adobe's, so every scenario is checked and tested in Make before cutover.
How the move runs
The same stages, in this order. We give a written plan and scope after the inventory.
- 1Inventory what runs today
Every workflow, its owner, its trigger, the apps it touches, how often it runs and when it last ran. Anything that has not run in months is a candidate to retire, not migrate.
- 2Map concepts and connections
Each step is matched to a Make module. Apps without a Make module get an HTTP call or a custom app. Credentials are re-created as Make connections owned by service accounts, not people.
- 3Set up Make Enterprise
Organization, teams and roles, single sign-on, folders and naming, error-handling standards, data stores and data structures, decided before the first scenario is built.
- 4Rebuild and test side by side
Scenarios are rebuilt in priority order and run against test data. Outputs are compared with the old platform's for the same inputs until they match.
- 5Cut over in waves
Triggers move a group at a time: webhook senders are pointed at Make, polling triggers start from the right record, and the old workflow is switched off, not deleted, until the Make scenario has run cleanly.
- 6Retire and hand over
The old workflows are archived and the source account closed. Each scenario is documented in plain language, and your builders are trained on Make.
What to watch when leaving Workfront Fusion
- Webhook URLs change: every system that calls the old platform has to be pointed at the new Make webhook.
- Polling triggers need a starting point, or the first Make run can pick up records the old platform already handled.
- OAuth connections are re-authorised in Make by someone who owns each account; passwords and tokens are never copied across.
- Usage is counted differently: estimate the operations each scenario will use (loops and iterators multiply them) before cutover.
- Imported blueprints can reference module versions or apps that differ in Make: swap and re-map those modules, then test.
- Fusion's licence is tied to Workfront: plan the Make plan and the Fusion end date together.
Make Enterprise features that help this move
As Make publishes them; the source is named on each card.
Roles and teams are managed inside the organization, so each migrated scenario has an owning team and only that team can change it.
Source: make.com/securityLog data is kept for 30 days by default, and the Enterprise Plan offers longer storage: useful when an audit asks what a scenario did.
Source: make.com/securityEnterprise Plan customers get 99.5% cloud service uptime and Enterprise support with defined SLAs.
Source: make.com/securityFrequently asked questions
Is Workfront Fusion the same as Make?
Fusion was built on Make's automation engine, so scenarios, modules, routers and filters work the same way. It is an Adobe product, though: its app list, module versions, licensing and support are Adobe's.
Can we export Fusion blueprints and import them into Make?
Where Fusion lets you export a scenario blueprint, Make can import blueprints. Some modules may need to be swapped or re-mapped because versions and apps differ, so we treat an import as a starting point and test every scenario.
Do we have to leave Workfront?
No. Make has an Adobe Workfront app, so Workfront stays your work management system and Make runs the automation around it.
Consultants in a Box is a Make partner and an independent consultancy; this page is ours, not published by Make or by Adobe. Make and the Make logo belong to Make; Adobe Workfront Fusion is a trademark of its owner. Facts about Workfront Fusion are kept general; check Adobe Workfront Fusion's own site for current details. Last reviewed November 6, 2026.
Ready to plan your move from Workfront Fusion?
Book a call. We inventory what runs today, map it to Make and give you a written migration plan and scope.