Hi everyone,
We're flagging an upcoming direction of travel early, and we'd like your view before anything is locked in.
The problem we're solving: Customization source files in IFS Cloud are stored as XML today. That format made sense once, but it’s now what stands between developers and a smoother day. PR diffs are noisy, merges are awkward, repositories grow heavier than they need to be, and modern tooling, including AI assistants and agents, can't reason over it reliably. The friction shows up most where it matters: maintaining customizations and seamlessly moving through upgrades.
Why now: An enhanced stabilization of the core IFS Cloud experience is one of our current priorities, and source persistence has been identified as a key piece of the puzzle. Moving to a clean, text-based format unlocks the things customers & partners tell us they want: a more AI-native development experience that genuinely works on their code; cleaner reviews, easier merges, lighter repositories, and a more productive workflow.
What this means in practice
- Readable diffs. Changing one field in a customization shows up as a one-line change, not a tangle of XML noise.
- AI that can help. Copilots and agents can more easily read, compare, and reason over your customizations, instead of choking on markup.
- Smoother merges. Fewer false conflicts when developers touch related files.
- Lighter repositories. Less to pull, push, and store.
- Better IDE experience. Impact analysis and code generation work from a single, clean source of truth.
How we're currently thinking about the migration Our intent is that this is a one-time, supported conversion of your customizations; no manual file editing, no per-file verification or large diffs shown in impact analyzer as a result.
- Spread Awareness: Enablement material through community updates (like this one), release notes, highlight in Impact Analyzer, flag in code editor
- IFS Developer Studio (primary). Alert developer, right-click workspace, run the conversion, commit the result.
- Ambition. We're aiming to make this as seamless and automatic as we can, with an assisted path available wherever a guided experience is needed.
Limitations
- Embedded entity-diagram data is not intended to be carried across; we may bring it back in a different form later.
- No backwards compatibility
- Applied to all supported core tracks
Where we are: This is a direction of travel. We have not yet committed to a finalized target release but have a near-term core release (and adjacent service updates) as working target and want to validate it with you first.
What we're asking
- Does this direction make sense for the way you build & maintain customizations?
- Does the migration path make sense? IFS Developer Studio one click automatic conversion, or may there be opportunities for an even better experience of how you'd most easily take this on?
- As we firm this up, how would you prefer to be kept informed & made aware of these changes: community updates, release notes, direct briefings, lifecycle experience like IFS Release Update Studio, something else?
The IFS Community is intended as the primary place for this conversation so please reply in this thread so others can see and build on your input.
Thanks, Alexander Härenstam, Product Manager - Developer Experience