Service

4D assistance

Your 4D application has been running your business for years. The question is rarely whether it works — it is how to get it onto a recent version, how to keep it maintainable, and how to make it reachable beyond the walls of your office.

We build and maintain 4D applications in production ourselves. That means we know not only the way things are done today, but also the code that was written ten or twenty years ago — and why it was written that way at the time.

Whether you are stuck on an old version, can no longer find a developer for your existing code, or want to open your application up through the browser: we first take a proper look at what you have, before proposing what should happen.

What we help with

The three questions we get most.

1

Conversion from older versions

From a stalled old version to a recent release, step by step. We first map out what breaks: removed and changed commands, plugins that no longer exist, 4D Write and 4D View that need to move to their Pro counterparts, and the move to project mode.

2

Code assistance

Support for your existing codebase: cleaning up, documenting, and where it pays off, moving to the modern approach with classes and ORDA. Also when your original developer is no longer around, or when you temporarily need an extra pair of hands alongside your own team.

3

From 4D application to web application

Opening up your existing logic and data through the browser, without rewriting everything. Often it is enough to offer the parts that customers, external partners or staff on the road actually need as a web application, and let the rest keep running as it does.

Migration audit

Know what you have before you decide.

  • ✓ An inventory of your structure, plugins and external connections, and what can and cannot come along.
  • ✓ An overview of removed and changed commands in your code, with an estimate of the work involved.
  • ✓ The silent breaking points: number and date formatting, mail sending, printing and reporting. These rarely raise an error — they produce a wrong result.
  • ✓ A migration path in stages, with a realistic estimate in time and budget.
  • ✓ A reasoned answer to the question of whether migrating, rebuilding or opening up delivers most for you.

Approach

In stages, not in one big leap.

A migration is rarely a big bang. We prefer to work in stages that can each be tested and put into production separately, so your people simply keep working while the environment changes underneath them. Your data and your daily operation are the starting point — not the version numbers.