Someone on a Delphi forum posted a one-line question last month: “Is Florence’s ARM support actually usable, or is this another false start?” Forty replies later, nobody had a clean answer. That’s the state of legacy migration in 2026. The tooling arrives before the confidence does.
Delphi 13, codenamed Florence, shipped this year with full native support for Windows on ARM. Developers can now compile true ARM64 binaries straight from the IDE, no emulation layer sitting between the code and the chip. On paper, that’s the milestone the Delphi community has wanted for years. In practice, it opens a much messier question: what does it actually cost to take a fifteen-year-old codebase and make it run natively on ARM hardware, without breaking the parts of the business that depend on it working exactly the way it always has?
This isn’t a press release recap. It’s a look at the real mechanics of that migration, and why “just recompile it” is the most dangerous sentence a project manager can say out loud.
The Part Nobody Budgets For: Dependency Archaeology
Start with the obvious step. You open the project, point the compiler at the ARM64 target, and hit build. It fails. It almost always fails.
Not because of your code. Because of the twelve third-party components you forgot you were using. Old Delphi projects accumulate dependencies the way attics accumulate boxes. A grid control from 2011. A reporting engine last updated in 2016. A COM wrapper someone wrote for a printer driver that the company stopped using during a different administration.
Each one needs to be ARM-compatible, rebuilt, or replaced. Some vendors have already shipped ARM64 packages. Others went quiet years ago. You’ll spend more time here than anywhere else in the process, and it’s the least glamorous kind of work imaginable: reading changelogs, testing builds, filing support tickets to email addresses that bounce.
IEEE’s research on technical debt makes a point that applies directly here: the biggest costs in legacy modernization are often invisible until the project is already underway. Nobody sees the dependency wall until they’ve walked into it.
Compiling Native Doesn’t Mean Behaving Native
Say you clear the dependency hurdle. The build succeeds. ARM64 binary, no emulation. Champagne, right?
Not yet. A binary that compiles is not a binary that behaves correctly. Pointer arithmetic that quietly relied on x86 memory alignment can misfire on ARM. Inline assembly, if there’s any left in the codebase (and in a fifteen-year-old Delphi app, there usually is), needs to be rewritten from scratch, because x86 assembly doesn’t port. Floating-point rounding can differ by a fraction that only matters if you’re doing financial calculations, which a lot of legacy Delphi apps are.
Windows Central reported this year that Windows-on-ARM users now spend the majority of their time in natively compiled apps, a real shift from just a few years ago when emulation compatibility was the whole conversation. That’s good news for the ecosystem. It also raises the bar. Users on ARM hardware in 2026 expect native performance, not a binary that technically runs but stutters through file I/O because someone left a legacy blocking call in the render loop.
Testing Across Hardware Is Its Own Project
Here’s where a lot of migration plans quietly fall apart. You test on your dev machine, it works, you ship it. Then the support tickets start rolling in from users on Snapdragon-based laptops running a slightly different driver stack, or from a regional office running an older ARM SKU nobody stocked for QA.
Cross-hardware testing for a genuine ARM rollout means running the compiled binary against a matrix of chipsets, OS builds, and regional configurations, because ARM devices are far less uniform than the x86 world Delphi developers grew up in. A build that’s rock solid on one Snapdragon variant can behave unpredictably on another six months later after a firmware update nobody flagged.
This kind of exhaustive, multi-variant testing isn’t unique to software running on new silicon. Regulated industries have been doing versions of this for years, just for different reasons. Take how a state gambling regulator handles a new platform before it’s allowed to go live for real users. Indiana runs one of the more rigorous state-level review processes in the US gaming industry, testing new software platforms across hardware configurations, geolocation accuracy, and payment integrity before anything reaches a live player. You can see the shape of that scrutiny in New Game Network’s full review of the Indiana market, which walks through exactly what platforms have to clear before they’re cleared for real money.
Gambling involves risk. If any of this ever applies to you personally, play within limits you’ve set in advance, and lean on BeGambleAware.org if it stops feeling optional.
The comparison isn’t perfect, obviously. Nobody’s auditing your inventory management app for problem-usage patterns. But the underlying discipline, testing a compiled build across every hardware and configuration variant it might realistically encounter before calling it done, is the exact discipline a lot of ARM migrations skip. Teams test on the machine in front of them and call it coverage.
What the Rebuild Actually Costs
Numbers help here, so let’s use some real ones. TechSpot reported this year that ARM PC users now spend roughly 90% of their time inside natively compiled apps, according to Arm’s own figures. That’s the market pulling hard toward native. If your Delphi app is still running under emulation for your ARM-device users, you’re already behind where the ecosystem has moved.
For a mid-sized legacy Delphi application, a genuine ARM64 migration usually breaks down something like this: two to four weeks auditing dependencies, another two to six weeks resolving or replacing incompatible components, then a testing phase that can run anywhere from three weeks to three months depending on how many hardware configurations you’re actually supporting in the field. Add QA cycles, staged rollouts, and rollback planning, and a “quick recompile” turns into a quarter-long project with a real budget line.
Small team. Tight budget. Old app that still runs the warehouse.
That’s the reality for a lot of Delphi shops. Florence’s ARM support is a genuine gift to the ecosystem, no argument there. But it’s a gift that comes with an invoice, and the invoice is bigger than most teams initially plan for.
Is It Worth Doing Now, or Waiting?
There’s no universal answer, but there’s a decent rule of thumb: if your app runs on hardware you don’t control (client machines, field devices, anything sold or leased to third parties) start the ARM audit now, even if the full migration waits. If your app runs entirely on infrastructure you own and control, you likely have more runway. X86 emulation on ARM has gotten good enough that most internal tools won’t hit a wall in the next year or two.
What you shouldn’t do is treat Florence’s ARM support as a switch you flip. It’s an opportunity to start the dependency audit that most legacy teams have been putting off since 2019. The compiler being ready doesn’t mean your codebase is.
Frequently Asked Questions
Does Delphi 13 Florence support Windows on ARM out of the box? Yes. Florence introduced native ARM64 compilation for Windows targets, letting developers build true ARM binaries directly from the IDE without relying on x86 emulation, a first for the Delphi toolchain in this form.
How long does a typical Delphi ARM migration take? For a mid-sized legacy app, expect two to four months end to end once you include dependency auditing, component replacement, and hardware-variant testing. Larger codebases with custom assembly or heavy third-party integration can run considerably longer.
Will my existing Delphi components work on ARM64 without changes? Not automatically. Pure Object Pascal components generally port cleanly, but anything relying on inline x86 assembly, specific memory alignment, or unmaintained third-party binaries will need rework, replacement, or a vendor update.
Is emulation still a viable option instead of migrating? For internal tools with light performance demands, yes, at least for now. But native ARM adoption is accelerating quickly, and users increasingly expect native-speed apps, so emulation is becoming a stopgap rather than a long-term strategy.
What’s the biggest hidden cost in an ARM migration? Dependency auditing. Teams consistently underestimate how many third-party components a legacy codebase relies on, and chasing down ARM-compatible replacements or updates for abandoned libraries eats more time than the actual code changes.
Florence’s ARM support is real progress, and it’s arriving at a moment when the ecosystem around it (chips, OS support, user expectations) has finally caught up enough to make native ARM Delphi apps a practical goal rather than a novelty. The teams that treat this as a scoped project, starting with an honest dependency audit, will get there in one piece. The ones that treat it as a checkbox will find out the hard way what Florence’s changelog didn’t warn them about.
