Modernising a legacy Clarion application without rewriting it

Start with what users actually complain about

Modernisation projects earn their budget on perceived improvement. In practice the complaints are dated screens, no access outside the office, manual re-keying into accounts packages, and slow reporting. None of those require a rewrite.

The usual modernisation ladder

Each rung is independently valuable, which keeps the programme fundable.

• Interface refresh: ribbons, docking panes, skinning and modern grids
• Document handling: PDF viewing, generation and archiving inside the application
• Integration: Xero, QuickBooks, Sage and Dynamics instead of re-keying
• APIs: publish or consume REST/SOAP so other systems can talk to the core
• Web and mobile surfaces for customers and field staff
• Reporting and analytics against a SQL back end

Add capability with wrapper templates

Most of the interface and productivity rungs are available off the shelf. Our wrapper templates cover Codejock user-interface components, Chilkat internet and encryption classes, DevExtreme web components, the Zoople HTML editor and a range of productivity and utility functions — each addable to an existing application in minutes, on ABC or Legacy, from Clarion 6 to Clarion 12.

When a rewrite is the right call

Sometimes it is. If the dictionary no longer reflects the business, if the data model blocks every requested change, or if the application depends on components that no longer exist on any supported platform, a staged replacement — module by module, sharing one database — beats another decade of patching. The key word is staged: big-bang replacements of business-critical systems fail far more often than they succeed.

Frequently asked questions

Can you work on an application you did not write?

Yes. Taking on inherited Clarion applications, documenting them and bringing them up to date is a large part of what we do.

What if the original developer has retired?

That is a common starting point. We begin with an audit of the dictionary, source, third-party dependencies and build process, then produce a prioritised plan before any code changes.

Do we need to move to SQL first?

Not necessarily. Interface, integration and document handling improvements can all be delivered on the existing data layer, and SQL migration can follow when it is justified.

Related guides