By Erick Jones, Solution Architect and Cofounder, Flexagon
The short answer
Oracle Functional Setup Manager (FSM) moves setup data from one Fusion instance to another. Flexagon Configuration Management governs that data across its whole lifecycle: documenting it, comparing it, tracking every change, migrating it with validation and rollback, and producing audit evidence.
FSM is included with every Oracle Fusion Cloud subscription and works well for loading configuration during an initial implementation. Most Fusion teams spend far more time after go-live, managing four mandatory updates a year, production fixes, and new entity rollouts. That is where FSM stops and Flexagon picks up.
What is Oracle Functional Setup Manager (FSM)?
Oracle FSM is the Setup and Maintenance engine inside Oracle Fusion Cloud Applications. Oracle describes it as the tool for managing implementation projects, executing task lists, and migrating setup data between instances (Using Functional Setup Manager).
FSM works through three core mechanics:
- Offerings and task lists. Setup tasks are generated from the offerings, options, and features you enable.
- Configuration packages. Setup data for an offering, functional area, or implementation project is exported to an XML/CSV package and imported into a target instance (Oracle SCM playbook, 25D).
- Setup data and comparison reports. Users can review setup data and compare a package against an environment before or after import.
FSM was built to load and migrate configuration for greenfield implementations, promoting setup one way from a test or gold instance into production. It is an implementation support tool, not a lifecycle configuration management suite.
What is Flexagon Configuration Management?
Flexagon Configuration Management is the modernized successor to ConfigSnapshot, now native to the Flexagon platform alongside FlexDeploy. Flexagon acquired ConfigSnapshot’s maker, UK-based Rookery Software, in April 2025, and the combined platform reached general availability in April 2026 (press release).
It manages configuration as one governed lifecycle of eight connected capabilities (product page):
| Capability | What it does |
|---|---|
| Document | Automated, audit-ready configuration documentation |
| Compare | Environments, entities, versions, and planned vs. actual |
| Track | Change over time, with attribution |
| Plan | A workspace to select and stage exactly what to migrate |
| Migrate | Dependency sequencing, pre-validation, rollback, and an audit trail |
| Analyze | Patch and upgrade impact analysis |
| Monitor | Configuration views tied to business and audit requirements |
| Comply | Automated compliance checks and segregation-of-duties analysis |
For Oracle Fusion Cloud, automated migration covers more than 1,000 setup steps across ERP, HCM, SCM, and CX.
Can Oracle FSM migrate individual configuration records?
No. FSM migrates whole offerings, functional areas, or implementation projects, not individual records. Oracle’s own documentation describes several related limits (Oracle SCM playbook, 25D):
- All or nothing. You cannot select specific records, which limits how and when FSM can be used after go-live.
- Limited step coverage. A significant number of Fusion setup steps cannot be loaded through FSM at all, and others only in part.
- Import never deletes. Records missing from the package stay in the target and must be removed or deprecated by hand.
- Rigid packaging. A package exported by offering or functional area can only be imported the same way, one offering at a time.
- Matching release levels. Source and target must be on the same release, which is hard to guarantee during quarterly (and sometimes monthly) update windows.
- Production changes must be re-keyed. Any change made directly in production must also be entered manually in test to survive the next migration.
Flexagon migrates at the record level. Teams select only the delta, validate it against the target, and migrate it with dependency sequencing and rollback.
Does Oracle FSM track configuration changes or detect drift?
No. FSM keeps no baseline library or change timeline, so it cannot show who or what changed a setting, or when. It also has no continuous drift monitoring between Dev, Test, UAT, and Production.
FSM’s visibility has three further limits:
- Extracted, not live. Extraction and comparison rely on exported data sets, not live settings.
- Not built for functional users. Results are presented in technical formats that business analysts cannot readily review.
- No governance layer. There are no approval workflows, rollback, segregation-of-duties analysis, or scheduled documentation.
Without these, teams fall back on spreadsheets, hand-built BR100 and MD50 documents, and weeks of evidence gathering before every audit.
Flexagon compares live settings across multiple Fusion environments in seconds, stores point-in-time baselines, attributes each change to who or what introduced it, and flags unexpected drift on a schedule.
How does Flexagon compare to Oracle FSM?
Flexagon covers FSM’s migration role, then adds the visibility, history, and governance FSM lacks.
| Capability | Oracle FSM | Flexagon Configuration Management |
|---|---|---|
| Primary purpose | Loading and migrating configuration for greenfield implementations | End-to-end configuration lifecycle |
| Migration selectivity | All or nothing by offering, functional area, or project | Record-level targeting, staged in increments |
| Setup step coverage | Limited; many steps cannot be loaded, fully or in part | 1,000+ automated steps across ERP, HCM, SCM, and CX |
| Documentation | Setup data reports from extracted data | Automated, schedulable, audit-ready, release independent |
| Environment comparison | Package vs. environment, from extracted data | Live settings across multiple environments in seconds |
| Point-in-time baselines | Not kept | Stored before deployments, quarterly updates, and upgrades |
| Change tracking | None | Who or what changed each setting, and when |
| Patch and update impact | Not shown | Changes from patches and quarterly updates identified directly |
| Drift detection | Manual | Scheduled comparisons flag unexpected change |
| Dependency handling | User manages import order | Automated sequencing |
| Validation and rollback | Optional comparison report; no rollback | Pre-validation against the target; rollback support |
| Deletes in target | Manual cleanup | Planned and governed in the migration |
| Approvals | None built in | Approval gates in the same pipeline as code releases |
| Compliance and SoD | Not covered | Automated checks, SoD and what-if analysis |
| Code and integrations | Setup data only | Also deploys code, OIC components, and reports |
| Cost | Included with Fusion; hidden cost in manual effort | Licensed platform that automates that effort |
Which Fusion use cases need more than FSM?
FSM handles initial implementation well. Nearly every post-go-live use case needs more.
| Use case | With FSM alone | With Flexagon |
|---|---|---|
| Initial implementation | Supported: export and import by offering or project | Supported, plus design documentation and build tracking |
| Ongoing enhancements | Re-export whole areas; re-key production changes in test | Select only the delta, validate, and migrate with approval |
| Rollouts to new entities | Manual re-entry or package edits | Compare entity to entity and replicate with adaptation |
| Oracle quarterly updates | Functional retesting only | Baseline before, compare after in test and again in production |
| Upgrades and Redwood conversions | Not covered | Baseline affected modules, compare once live |
| Environment drift | Not detected until something breaks | Scheduled comparisons surface differences early |
| Pre-deployment checks | Optional package comparison | Planned-vs-actual comparison before every release |
| Production support | Manual investigation | Side-by-side pod comparison in minutes |
| Audit and SOX evidence | Rebuilt by hand from tickets and emails | Generated as part of the process |
| Segregation of duties | Not covered | SoD analysis with what-if modeling |
| Integration protection | Not covered | Value sets, flexfields, and security setup baselined and compared |
| Environment refresh | Not covered | Baseline before refresh, re-apply the delta after |
| Multi-pillar estates | One offering at a time | One governed process across ERP, HCM, SCM, and CX |
Drift, quarterly updates, and audit preparation are where the gap costs the most. SOX programs are getting more expensive: the KPMG 2025 SOX Survey found average program hours rose 32% in two years, while only 17% of controls are automated. In our work with Fusion customers, assembling configuration evidence for a single audit cycle typically takes two to four weeks without dedicated tooling.
When is Oracle FSM enough?
FSM can be enough for a team that is mid-implementation, runs a single Fusion pillar with few environments, and has light audit requirements. In that situation, moving a validated build from test to production by offering is exactly what FSM was designed for.
The case for dedicated configuration management grows when any of these apply:
- You are live on Fusion and making regular post-go-live changes.
- You run multiple pillars (ERP, HCM, SCM, CX) or many environments.
- You face SOX, SOC, or internal audit requirements on configuration changes.
- Quarterly updates regularly cause unexpected behavior or retesting effort.
- Your team maintains configuration documentation in spreadsheets.
Does Flexagon replace Oracle FSM?
No. FSM remains where implementation task lists run, and Flexagon does not change that. Flexagon works alongside FSM but does not depend on FSM configuration packages.
It works directly against each Fusion pod through three native mechanisms: Fusion web services, the Fusion data loader, and automated driving of the Fusion browser interface for setups no API exposes. That removes FSM’s offering-level exports, matching-release requirement, and import-only behavior, and makes targeted migration with validation and rollback possible.
Frequently asked questions
Is Oracle FSM free?
FSM is included with every Oracle Fusion Cloud subscription. Its hidden cost shows up in manual documentation, rework, and audit preparation.
Can FSM delete configuration in the target environment?
No. FSM imports never delete. Records missing from the package must be removed or deprecated by hand.
Does FSM work across different Fusion release levels?
No. Source and target must be on the same release level.
How do I see what an Oracle quarterly update changed in my configuration?
FSM does not show this. Flexagon baselines configuration before the update and compares it afterward, first in test and again in production.
What happened to ConfigSnapshot?
ConfigSnapshot is now Flexagon Configuration Management, a modernized version native to the Flexagon platform alongside FlexDeploy.
Which Fusion pillars does Flexagon support?
ERP (Financials), HCM, SCM, and CX, plus related services such as OIC and OTBI/BIP.
See it in your Fusion environment
FSM answers one question: how do I move this setup from here to there? Flexagon answers the ones that follow. What is configured? What changed, and who changed it? Does production match what we tested? Can we prove it to an auditor?
Request a demo to see Flexagon Configuration Management on your Fusion configuration.
Questions about your Fusion configuration? Our solution architects are happy to walk through your environment.