The short version.
- Count every rule, workflow, scheduled task and trigger before you estimate anything.
- Sort each one: becomes flows, becomes flows plus something else in Okta, or does not become a flow.
- Rebuild behaviour, not code. Translating line by line carries the old platform’s shape into the new one.
- Move in small waves, each one traced back to the objects it replaces.
1. Inventory before you estimate
Export the platform’s configuration and list every object that does something on its own: rules, workflow definitions, scheduled tasks, lifecycle triggers, policies, and the scripts that run beside them (PowerShell, Python, shell). For each, note what starts it, what it calls, and what it changes. The count is often well above what the team remembers.
2. The decision table
| What it does | In Okta |
|---|---|
| Reacts to a joiner, mover or leaver | A flow started by an Okta event, with a scheduled safety net. |
| Runs on a schedule and changes access | A scheduled flow. |
| Shared logic called by other rules | A helper flow with inputs and outputs. |
| Queries a database directly | A flow, plus an API in front of that database. A flow can only call HTTP APIs. |
| Reads or writes files on a server | A flow, plus a table or a storage API in place of the file. |
| Asks a person to approve | Okta’s access request features, or your service desk. Flows carry the steps before and after. |
| Runs inside an account import (mapping, correlation) | Not a flow. The app integration’s import and profile mapping do this. |
| Computes one attribute | A profile mapping expression where it fits on one line; a flow where it needs a lookup. |
| Shapes an access certification | The campaign’s own settings in Okta Identity Governance. |
| Housekeeping of the old platform | Nothing. Do not rebuild it. |
3. Rebuild in waves
Take a trigger and everything it launches as one wave: five to ten objects. Write down what each one must do as testable statements (“when a user’s department changes to Finance, add them to the group FIN-Base”), build to those statements, and test against them. Keep the list: it is the evidence that the new flows replace the old logic.
4. Four traps
- Old and new values. A rule that compares an attribute’s old value with its new one needs the old value stored somewhere; the event may not carry it.
- Deletes. Replace delete with suspend wherever you can. A deleted account in a downstream system rarely comes back with a click.
- Hidden dependencies. A rule library used by twenty rules must move first.
- Secrets in code. Old scripts hold passwords. They belong in a connection, never in a flow.
5. Do the inventory with Assay
Assay’s Migrate reads the export in your workspace, without a model, and lists every automation object with what starts it, what it uses and a verdict with reasons: becomes flows, partly, or not a flow. The inventory is free and removes anything that looks like a secret before it is stored. You then choose a wave; its source is read into requirements that name the object each came from, and the flows are designed, priced and built against that list. It reads source; it does not run it, and it does not move data.
Sources
- Okta Workflows documentation: flow types, helper flows and the API Connector, and tables.
- Okta documentation: profile mappings, imports, and Okta Identity Governance (access requests and certifications).
- Your current platform’s own export and object reference.
Okta and Okta Workflows are trademarks of Okta, Inc. Assay is independent of Okta. Card names and limits change: check Okta’s current documentation and test in a preview org before you rely on any pattern here.