Service · Software development

Replace Crystal Reports with a modern reporting solution.

One press of a button and out comes an invoice, an overview or a management report, generated from an .rpt file that has often been in use for twenty years, built on a Delphi, FoxPro or older .NET system. Crystal Reports usually still runs fine, until the runtime is no longer updated, the licence changes via SAP, or the one colleague who could edit the reports is no longer there. We replace that standalone reporting layer with a modern solution, without losing the knowledge that currently exists only within the old files.

Arrange an introductory call See our work

▤

A reporting layer that nobody dares to touch anymore.

Crystal Reports rarely stands alone. In almost every project we encounter, it sits as a separate reporting layer on top of a business application that is itself many years old: a Delphi application, a FoxPro system or an older .NET or VB6 environment. The underlying application handles the business logic, while Crystal Reports provides the invoices, overviews and management reports around it, via an SDK that was integrated decades ago and that nobody has touched since.

That works, until it doesn't. Crystal Reports is owned by SAP, and not every older version of the runtime has been carried forward to the latest platforms; some ran for a long time only as a 32-bit component. Newer versions fall under a different licensing model from the version you originally started with. And the reports themselves, the .rpt files with their embedded queries and formulas, are designed so that you can only open them in the Crystal Reports designer or not at all. As a result, knowledge of what a report actually does is, quite literally, locked up with whoever can still operate that designer, often a single person.

The result is a silent dependency: reports that management, accounts or the client see every week, but that nobody can change without first working out what was ever built into them. Meanwhile the rest of the organisation keeps working with static PDF exports, while other departments have long been used to dashboards where they can explore the data themselves. This fits a broader pattern we often see with replacing legacy software and modernising legacy software: the reporting layer is often not the first thing an organisation thinks of, but it is the first place where the pain becomes felt.

How we approach Crystal Reports projects.

Assessment first

We map out which .rpt reports are actually in use

Rebuilding queries

The logic in the report is decoupled and made readable

Modern BI layer

Built-in dashboards or a BI tool with direct data source integration

Shared knowledge

Documentation instead of knowledge locked in a single .rpt file

Three steps to move away from Crystal Reports.

You don't replace a reporting layer by copying all the .rpt files across one-to-one. Most of the value lies in first looking carefully at what is actually being used, then rebuilding the underlying logic, and only then choosing the new form of reporting.

Step 01

Taking stock of which reports are genuinely used

Almost always fewer than the reports folder suggests

In most organisations, dozens of .rpt files sit in the reports folder, built up over the years for projects, audits or one-off questions that were long since finished. For each report, we establish when it was last run, by whom, and for what purpose, rather than relying on what is assumed to "still matter". This happens through conversations with the people who actually use the reports, usually in accounts, management or customer service, supplemented by what the system itself shows about usage frequency.

The result is a compact list of reports that demonstrably serve a function, separate from those that were once built but have since become redundant or exist in duplicate under a slightly different name. This inventory is the foundation of the rest of the project: the sharper the scope, the less we need to reconstruct and the smaller the risk that something has been overlooked.

Usage analysisStakeholder interviewsReport auditScope definitionRemoving duplicates

Step 02

Rebuilding the underlying queries and data sources

Extracting the knowledge from the .rpt format

A Crystal Reports file is not simply a standalone report on a clean data source; it often contains its own queries, formulas, groupings and calculations that determine what ends up in the report. That logic is hidden in a file format that can only be opened with the Crystal Reports designer, and is therefore effectively invisible to everyone except whoever originally built the report. We reconstruct that logic as readable, documented queries or views on the underlying database, independent of the .rpt file.

Each rebuilt query is placed alongside the old report output and compared, row by row, until the results match. Where the report contained outdated or illogical filters, we flag these explicitly to the user rather than silently carrying them over or dropping them. In this way you don't end up with a copy of the old problem in a new guise, but with data logic that anyone in your technical team can read and adjust.

Query extractionData source integrationValidation against previous outputDocumentationViews/data model

Step 03

Replacing it with a modern reporting or BI layer

Built-in dashboard or BI tool, determined per report

Once the logic has been rebuilt, we choose the format that suits each report best. Reports that sit close to a single workflow, such as an invoice overview within the application where the invoice is created, we embed as a dashboard directly in the application itself. Reports that are used by several departments and need to be filtered, combined or sliced are a better fit for a BI tool with a direct connection to the data source, so users can filter for themselves without asking a developer.

Both routes put an end to the "one-to-one PDF report" thinking of Crystal Reports. Instead of a static file that you have to open and export, you get an environment that moves with the live data and in which several people can build their own insight. We always set out the choice between both routes for you, with the pros and cons made concrete for each report.

Embedded dashboardsBI tool with live connectionSelf-service reportingRole-based accessNo more .rpt files

What you have at the end.

Reporting that is no longer tied to one file format and one person, but is readable, documented and maintainable by several people.

Reports in production

As a built-in dashboard, as a BI environment, or a combination of both.

Documented queries

Readable views and data model, no longer hidden away in an .rpt file.

Report overview

Which reports have been kept, merged or retired, and why.

Self-service for users

Where possible, users can filter and drill down themselves, without a developer.

Managed service (optional)

Ongoing development of reports and dashboards under a maintenance contract.

When replacing Crystal Reports becomes unavoidable.

Four situations in which postponing is no longer sensible, and in which we are usually first invited to an inventory meeting before anything concrete is planned.

Runtime

The runtime or licence is under strain

Older Crystal Reports runtimes have not all kept pace with newer platforms, and some ran for a long time only as a 32-bit component. Newer versions fall under SAP's licensing model, SAP being the current owner of the product, which brings different terms from the version you originally started with. Once a platform upgrade or server move is on the horizon, the reporting layer suddenly becomes the bottleneck.

Skills

The only administrator has left or is about to leave

The .rpt files were originally built by one developer or power user who knows the Crystal Reports designer. That person is retiring, changing roles or has already left, and nobody else dares to change the reports without first spending days working out what is actually in them.

Embedding

The reports need to move to the web

The underlying application is being replaced by a web application, but Crystal Reports was designed for a desktop environment and is difficult to embed in a modern web stack. Once the application itself is modernised, for example through a Delphi modernisation or by replacing a COBOL system, the reporting layer has to move with it, and that is the moment to move straight to a modern form as well.

Forecast

Users want to filter for themselves

Management and operational teams have become used to dashboards elsewhere in which they can drill down, filter and compare on their own. A static PDF report that they have to request from the IT department feels like a step backwards, even when the underlying figures are correct.

Risks we address explicitly.

Reporting affects the figures your organisation steers by. Four risk categories that are identified upfront in every Crystal Reports project.

Report loss

A report is overlooked

When decoupling an old reporting layer, there is a risk that a report which only runs a few times a year is overlooked. We therefore take stock not only based on daily use, but also explicitly ask finance, legal and operational departments whether there are periodic reports that do not appear in the everyday picture.

Figures

Discrepant results after rebuilding queries

When the logic is reconstructed from a .rpt file, a small difference in a filter or rounding can lead to a different figure. We validate every rebuilt query, report by report, against the old output, and explicitly raise any discrepancy before the old report is switched off.

Adoption

Resistance to letting go of familiar PDFs

Users who have worked with a fixed report for years initially find a dashboard unfamiliar, even when it offers more capabilities. We involve the key users from the inventory phase onwards and, where possible, keep the layout of a new dashboard recognisable from the old report.

Transition

Dependence on a single key person during the transition

If the sole administrator of the old reports is still with the organisation, we schedule that knowledge transfer as a fixed part of the project, with documentation as the outcome rather than verbal knowledge that again rests with one person.

How a Crystal Reports project runs.

01Introduction→ 02Inventory→ 03Queries & build→ 04Rollout & embedding

Step 01

Introduction

Which reports exist, who uses them, and where the pain lies: the runtime, the licence or the knowledge. A no-obligation conversation with IT and the main report users.

Step 02

Discovery & scope

We map actual usage per report, speak with the user groups, and decide which reports to keep, merge or retire.

Step 03

Rebuilding queries & development

The logic from the .rpt files is reconstructed as readable queries, validated against the old output, and incorporated into dashboards or a BI integration.

Step 04

Rollout & embedding

Reports are rolled out in phases alongside the old version, users are trained, and the old Crystal Reports layer is only switched off once the new reports are confirmed.

From Crystal Reports to a modern reporting stack.

Crystal Reports turns up in many different environments in practice. Besides this page, our pages on modernising Delphi applications and replacing Cobol systems may also be relevant when the reporting layer is part of a broader modernisation, as well as our wider approach to replacing legacy software.

Where we are starting from

Crystal Reports (.rpt)SAP Crystal Reports SDKDelphiFoxProVB6Legacy .NET WebForms

Target stack, reporting & BI

Built-in dashboardsPower BIReact / Next.jsPostgreSQLSQL Server views

Migration & integration

Query extractionData validationDirect data source integrationAPI layerRole-based access

Frequently asked questions.

Why not simply keep running the existing .rpt files?

You can, as long as the runtime is still supported and the know-how to adapt the reports is still in-house. The problem is that both usually disappear at the same time: older Crystal Reports runtimes have not all been carried forward to the latest platforms, and licences for newer versions fall under SAP, the current owner of the product. Once the runtime or licence becomes a showstopper, or the only colleague who understands the .rpt files leaves, postponing is no longer an option. We therefore advise not to wait for that moment, but to replace the reporting layer in a controlled way while there is still time to do it carefully.

What happens to reports that nobody really uses any more?

We drop those, and that is more often the case than organisations expect. Almost every reports folder contains .rpt files that were once built for a specific project or a one-off question and have not been changed or opened since. We inventory actual usage per report, not assumed usage, and only rebuild what can demonstrably still serve a purpose. That saves not just build time, but also stops the new environment from inheriting the same clutter as the old one.

Can we switch over without losing any figures or introducing errors?

Yes, provided the underlying queries are carefully rebuilt and validated. Crystal Reports files often contain query logic, formulas and groupings that exist only within the .rpt file itself, not in the database. We reconstruct that logic as readable, documented queries or views, and compare the output report by report against the old results until the figures match. Only then do we permanently replace the old report.

Does everything have to move to a BI tool, or can it be done within the application itself?

Both routes are possible and we choose case by case. Reports used mainly by one department and sitting close to an existing process are often embedded as a dashboard in the application itself, right next to the workflow the figures come from. Reports that several departments slice, filter or combine are a better fit for a BI tool such as Power BI with a direct connection to the data source, so users can drill down themselves without needing a developer.

What if the only person who maintained the reports has already left?

That is a common reason to bring us in, not a blocker. We open the existing .rpt files, reconstruct the queries and formulas contained within them, and check the output with the colleagues who read the reports every day, even if they are not technical. That way we recover the knowledge from the file format and capture it in documentation and readable queries, rather than leaving it in a single .rpt file that only one person can open.

Does this also work if Crystal Reports runs on a Delphi or FoxPro application?

Yes, that is actually the most common situation we encounter. Crystal Reports has often been added as a separate reporting layer to a Delphi, FoxPro or older .NET/VB6 system, with the reporting engine linked in through a standalone SDK. We can replace the reporting layer while the underlying application is still running, or combine this with a broader programme if the application itself is also due for replacement. See also our pages on modernising Delphi applications and replacing Cobol systems for that wider approach.

What determines the timeline of such a project?

The number of reports that genuinely need to be kept after the inventory, the complexity of the underlying queries and formulas, the number of data sources involved, and the choice between embedded dashboards or a BI tool. A limited set of straightforward reports with one data source is a different project from dozens of reports combining several systems. We give an honest estimate after the inventory phase, not before, because any figure given without seeing the real scope is a guess.

Will we remain the owner of the new reporting environment and the underlying data?

Yes, fully. The documented queries, data model, dashboards or BI integration will be in your name, in your own environment or database. You aren't tied to a specific reporting vendor, and the knowledge that once lived only in .rpt files is captured in readable documentation that people across your organisation can understand.

Talk to us about your Crystal Reports reports.

A free, 30-minute introductory call. We'll look at which reports you run, where the pain points are, and whether replacing them is the right move right now, even if it turns out your current reporting layer is still fit for purpose for the time being.

Schedule an introductory call Email fabian.vandijk@appfront.nl