← All resources
Clarion language

Upgrading Clarion: moving an application from Clarion 6 to Clarion 12

Applications built in Clarion 6 or Clarion 7 still run, but staying there costs you: modern Windows behaviour, current third-party components, newer database drivers and reasonable developer tooling all assume a current compiler. An upgrade to Clarion 12 is normally a sequence of controlled steps rather than one leap.

What actually breaks

Most upgrade pain comes from the ecosystem around the code, not the language itself.

  • Third-party templates and classes compiled for an old version
  • Hand-written embed code that assumes old class internals
  • Old ActiveX or OCX controls with no modern equivalent
  • Database drivers, especially legacy ISAM and older ODBC layers
  • Report layouts and fonts that shift under newer Windows DPI handling

A safe sequence

Work in a copy of the application and in this order: get it compiling, then get it correct, then get it improved.

  • Inventory every third-party product and confirm a current-version release exists
  • Take a full dictionary and source backup, and put everything under version control first
  • Upgrade the compiler and resolve build errors before changing any behaviour
  • Retire dead ActiveX controls and replace them with supported components
  • Re-test reports and printing under current Windows DPI settings
  • Only then take on SQL migration, UI refresh or new functionality

Do the database migration separately

Moving from TopSpeed files to SQL Server or PostgreSQL is its own project with its own risks: null handling, key semantics, concurrency and transaction behaviour all change. Combining it with a compiler upgrade makes failures far harder to diagnose. Sequence them, and keep a working fallback build at every stage.

Keeping the business running

Upgrades stall when they block ordinary support work. Run the upgrade branch alongside live maintenance, merge frequently, and set a hard cut-over date with a pilot group of users. A short pilot on real data catches printing, locale and performance issues that no test environment reproduces.

Frequently asked questions

How long does a Clarion upgrade take?
It depends almost entirely on third-party dependencies and the volume of hand-written embed code. A clean application with current components can be recompiled in days; one leaning on abandoned ActiveX controls takes considerably longer.
Do we have to convert Legacy to ABC at the same time?
No, and we would advise against it. Upgrade the compiler first and treat a chain conversion as a separate decision.
Can you do the upgrade for us?
Yes. We take on Clarion upgrade and modernisation projects, including component replacement, SQL migration and post-upgrade support.

Want to take this further?

Discuss an upgrade

Related guides

What is the Clarion programming language?

A practical introduction to Clarion: what it is, what it is used for, why business applications built with it are still running after 30 years, and where it fits today.

Clarion ABC vs Legacy: which template chain should you use?

The difference between the ABC and Legacy (Clarion) template chains, what each means for maintenance and third-party add-ons, and how to decide when converting is worth it.

Modernising a legacy Clarion application without rewriting it

Why rewriting a working Clarion system is usually the wrong first move, and the modernisation steps that deliver value earliest — UI refresh, APIs, cloud accounting and mobile access.