Clarion Modernization:
Upgrade within Clarion, or move to .NET.

Clarion is still sold and updated: Clarion 12 shipped on May 15, 2025, and it still produces 32-bit programs. Most Clarion systems are template-generated Windows applications on TopSpeed files. There are two realistic paths, upgrading within Clarion or migrating data and screens to .NET, and the assessment decides between them.

Book a free 1-hour consultation →

At a glance

Legacy sources: Clarion 5/6 · Clarion 7/8 · Clarion 9/10/11 · Clarion 12 · ABC templates · Legacy (Clarion) templates · TopSpeed .TPS files · Clarion#
Modern targets: Clarion 12 · C# .NET 10 · SQL Server · PostgreSQL · SQLite · ASP.NET Core web · WinForms or WPF
First step: Free 1-hour consultation, then a fixed-scope assessment
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery

What to know before you modernize

What Clarion is and who still runs it

Clarion began as a DOS product in 1986. Through the 1990s it became a Windows rapid-development tool built around a data dictionary and an Application Generator: you describe tables, keys, and relationships once, and templates generate browse windows, forms, and reports. In 1992 the company merged with Jensen and Partners International and later became TopSpeed Corporation; the product line is now developed by SoftVelocity. That model produced a lot of line-of-business software written by small teams and independent developers. Those programs are still running because they were built to be maintained by one or two people and nothing in them expires on its own. The risk is rarely the language. It is a Win32 program, a proprietary file format, and a small pool of people who can read the generated code.

Which Clarion you have, and what it implies

Clarion releases from 5 and 6 through 7, 8, 9, 10, 11, and 12 differ in ways that matter for the first month of work. Older builds, roughly 5.x and 6.x, tend to have no Unicode, an older runtime library, and third-party templates that may no longer be sold. Clarion 11 added a SQLite driver and TopSpeed encryption, and the IDE runs on 32-bit and 64-bit Windows, so features differ noticeably between a Clarion 6 build and a current one. The version number is only half of it. The other half is which template chain the application uses, ABC or the older Legacy (Clarion) chain, and which third-party template sets are embedded. The first deliverable of any engagement is a list of each application, its Clarion version, its template chain, and every add-on it depends on. Add-ons deserve their own line in that list: some are still sold, some ship source, and a binary-only template from a vendor that no longer exists can decide whether an in-place upgrade is practical.

Support status: the vendor still ships Clarion

This is the fact that most affects the decision. Clarion 12 was released on May 15, 2025, and the release announcement promises 100% backward compatibility and says existing projects should compile. The vendor's home page presents it as the latest release and as a step before a 64-bit version, and asks customers to renew their subscription. The vendor blog was still posting Unicode beta builds as of October 28, 2026. The 64-bit compiler is the open question. A September 2023 post said the 64-bit release would follow Clarion 12 by December 2024; as of the vendor's current home page it is still described as planned. We treat any 64-bit date as unconfirmed and do not plan around it.

What breaks or blocks on Windows 11

A Clarion application compiled by Clarion 12 is a 32-bit program, and 32-bit programs run on 64-bit Windows 11 through the WOW64 layer. So the application itself usually runs. What fails is the surrounding environment: 32-bit ODBC data sources that must be created with the 32-bit administrator, old printer and label drivers, ActiveX and OCX controls that no longer register, third-party DLLs compiled for old runtimes, and installers that assume Windows XP folder rules. The vendor blog also shows Windows 11 is a live concern for the IDE: an August 2026 beta build fixed menus and mouse clicks going dead when another program's always-on-top window overlapped a Clarion window. The assessment tests the list of dependencies, not just whether the executable launches.

Application Generator, ABC and Legacy templates, and hand code

A Clarion application is mostly a .APP file, a dictionary, and templates. The templates generate Clarion source, and developers add their own code at embed points. Two template chains exist: ABC, which generates code around object-oriented Application Builder Classes, and the older Legacy chain, which generates procedural code. The vendor's own posts treat both as supported, and the templates ship in source form. For modernization, the ratio of generated code to hand-written embed code is the key measurement. Generated code can be regenerated or discarded because its rules live in the dictionary and the template settings. Embed code is where the business logic lives, and that is the part that needs to be read, documented, and moved. We inventory embed points by procedure and classify each as UI behavior, validation, calculation, or integration.

Data: TopSpeed files and SQL drivers

Clarion reads and writes ISAM and SQL data through file drivers. TopSpeed (.TPS) is its own indexed file format, and the vendor ships a TopSpeed driver; the 2026 Unicode work adds a separate TopSpeedW driver for wide strings. Other drivers cover flat files and dBase-family formats, ODBC, and native drivers for Microsoft SQL Server, SQL Anywhere, Oracle, and, from Clarion 11, SQLite. Moving off TPS to a SQL database does not require leaving Clarion: the dictionary can point at SQL Server or another back end and keep the application. If the goal is .NET, the data is extracted, the key and relation rules in the dictionary become the schema, and the migration is rehearsed against a copy. Extraction scripts are written per table, and key and index definitions are compared against the SQL schema so lookups return the same rows in the same order.

Keeping the system running during migration

Most Clarion systems cannot be switched off while a replacement is built, because they take orders, post invoices, or run a counter. The workable pattern is to stabilize first and replace second. Move the data to a SQL back end, which Clarion's own drivers allow, so that both the old program and any new code read the same tables. Build replacement screens and reports one module at a time and run them in parallel against the live data. Retire each Clarion procedure only when its replacement has matched the old output for a full business cycle. A rollback path is kept for every cutover. This takes longer than a single big release but never leaves the business without its program, and it lets you stop at any module boundary if staying on Clarion turns out to be the right answer.

Screens, reports, and the user interface

Generated browse and form windows map well to modern equivalents because their structure is declared: a browse is a list over a key with filters, and a form is a set of fields with validation. Hand-placed controls, custom window procedures, and embedded API calls need individual treatment. Reports are a separate task. Clarion's report engine is tied to the application, so each report is rebuilt as a SQL query and a report definition in whatever target reporting tool is chosen, and the printed output is compared page by page against the original. The vendor's recent updates add a default font setting and a font-changing command-line tool to the IDE, which is useful if the plan is to stay on Clarion and refresh the look. A web front end is a different decision; it means rebuilding the UI, not recompiling it.

The paths: stay, upgrade within Clarion, or migrate

Because SoftVelocity still ships Clarion, staying on it is a legitimate answer. Upgrade within Clarion when the application works, the data fits, someone can maintain it, and the goal is a supported toolchain: move to Clarion 12, replace dead third-party templates, and move TPS data to a SQL back end if concurrency or reporting is the pain. Migrate to .NET when you need a browser or mobile interface, integration with systems that expect REST or modern identity, a team that writes C#, or you cannot find Clarion developers. Be careful with the 64-bit argument: it is an argument for waiting, not for leaving, unless a 64-bit-only dependency forces the issue today. A bridge is also possible, where new features are built in .NET against the same SQL data while the Clarion program shrinks.

Rewrite vs strangler fig →

Choosing a .NET target and proving parity

If the answer is migration, the usual target is C# on .NET 10 with a SQL Server or PostgreSQL database, delivered as an ASP.NET Core web application or a Windows desktop client, depending on how users work. Clarion# was announced and developed by the vendor around 2009 and 2010 as a way to carry Clarion to .NET, but we do not rely on it for a plan and recommend verifying its present status with the vendor before considering it. Parity is proved with a captured set of real inputs: representative records, the reports users print, and the calculations that drive money or compliance. The old and new systems are run on the same data and the outputs compared before any cutover. Dictionary rules and embed code are traced to test cases so nothing is lost silently.

Start with an assessment for a Clarion codebase

For a Clarion codebase the read-only assessment inventories each .APP and its Clarion version, the template chain (ABC or Legacy), every third-party template and class library with its vendor status, the dictionary and file definitions, the data files by driver (TopSpeed, ODBC, SQL), embed code volume by procedure, report definitions, external DLL, OCX, and API calls, 32-bit dependencies, the build and installer process, and what testing exists. Nothing is run against production and nothing is changed. The result is a written recommendation: stay on Clarion 12, upgrade the data layer within Clarion, bridge, or migrate, with the reasons. The fee is quoted after the free 1-hour consultation and is creditable toward a later modernization project.

About the assessment →

Deliverables

  • Written recommendation: stay on Clarion, upgrade within Clarion, bridge, or migrate
  • Inventory of applications, Clarion versions, template chains, and third-party add-ons
  • Embed-code map separating generated code from hand-written business logic
  • TPS-to-SQL data migration plan with a rehearsed, repeatable extraction
  • Report and screen replacement plan with page-by-page parity checks
  • Cutover and parallel-run plan that keeps the current system working

Common questions

Does a Clarion application still run on Windows 11?

Usually yes. Clarion programs are 32-bit and run on 64-bit Windows 11 through the WOW64 compatibility layer. What tends to fail is the environment around them: 32-bit ODBC data sources, old printer drivers, ActiveX controls that no longer register, and third-party DLLs. The assessment tests those dependencies directly instead of only checking that the executable starts.

Is Clarion still supported?

The vendor, SoftVelocity, still sells and updates it. Clarion 12 was released on May 15, 2025, and the vendor blog was still posting Unicode beta builds in October 2026. Older releases such as Clarion 6 are not what the vendor is shipping now, so an old application usually benefits from at least moving to a current release.

Should we upgrade to Clarion 12 or migrate to .NET?

Upgrade when the application works, the data volume is manageable, and you have someone who can maintain Clarion code. Migrate when you need browser or mobile access, modern integration, or a C# team, or when you cannot hire Clarion developers. Because the vendor still ships the product, staying is a legitimate outcome, and the assessment will say so if it applies.

Is Clarion 64-bit?

Not yet. Clarion 12 produces 32-bit programs. The vendor says 64-bit is planned and that code compiling cleanly in Clarion 12 is meant to carry over, but a 2023 vendor post that targeted December 2024 was not met and no current release date is published. Do not base a project schedule on a 64-bit date until it exists.

What happens to our TopSpeed .TPS data?

It can stay in TPS if the application stays on Clarion, or move to SQL Server, PostgreSQL, or another back end. Clarion has SQL drivers, so a move to SQL can happen without leaving Clarion. For a .NET migration, the data is extracted per table, loaded into a schema derived from the dictionary, and compared with the source before cutover.

Can we keep using the system while it is being migrated?

Yes. The usual approach is to leave the Clarion application in service, move data to SQL first, and build replacement screens and reports against the same data. Users switch module by module after a parallel run. The old program shrinks over time instead of being replaced in one weekend cutover.

How long does Clarion modernization take and what does it cost?

It depends on scope. Project work ranges from a few weeks (virtualization) to several months (re-architecture). Every engagement starts with a free 1-hour consultation. Price and schedule are fixed after the fixed-scope Legacy Software Assessment, and the assessment fee is creditable toward a later modernization project.

Do we have to rewrite everything to leave Clarion?

No. Generated windows are declared in the dictionary and templates, so they can be rebuilt from their definitions. The part that needs careful work is the hand-written embed code, the reports, and the data. A bridge approach lets new features be built in .NET against shared SQL data while the Clarion application continues to run.

Sources

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.