Crystal Reports: how to inventory hundreds of .rpt files before a migration

Reporting is what derails legacy migrations, and it derails them late. The application gets scoped, the budget gets approved, and then somebody discovers four hundred Crystal Reports that nobody counted, each with its own connection string, pointing at a database that is about to change shape.

The good news is that the inventory almost always makes the project smaller rather than larger. This guide is the method.

Why reporting breaks during a migration

The core fact, and the one that surprises people: a .rpt file is largely self-contained. It typically holds

• its own database connection details
• its own SQL, often written directly into the report rather than calling a stored procedure
• its own formula logic, written in Crystal's formula language
• its own grouping, sorting and formatting rules

So the reports are not really part of your application. They are a parallel system that happens to point at the same database. Change the database underneath and every report that reads a changed table stops working, all at once, with no warning at build time.

It is also why reports survive application changes that everybody expected to break them, and then break during a change nobody thought was risky.

Step 1: find every report

Reports are rarely in one place. Search for *.rpt across everywhere, not just the obvious folder:

• The application server and any reporting server
• Shared network drives, including departmental ones IT does not manage
• Individual desktops, particularly finance and operations staff
• Any scheduling tool that emails reports out overnight
• Attachments in shared mailboxes, which is where the version somebody actually uses often lives

For each one, record the filename, where it was found, the tables it references and the connection it points at. That last field is what tells you whether it will survive the migration.

Step 2: work out which are actually used

This is where the project shrinks, and it is worth doing carefully because the saving is large.

Ways to establish real usage, in rough order of reliability:

• Scheduler configuration. Anything on a schedule is being produced. Whether anybody reads it is a separate question worth asking.
• File access timestamps. Crude, and affected by backups touching files, but a report last opened in 2019 is a strong signal.
• Application logs, if the application launches reports and logs it.
• Ask the people. Go to finance and operations with the list and ask which they run. This is the most reliable method and the most commonly skipped.

In our experience the live set is a small fraction of the total. A system with four hundred report files often has thirty that anybody would notice disappearing. The other three hundred and seventy become an archive, which costs almost nothing compared with rebuilding them.

Step 3: recover the logic in the formulas

Crystal formulas are worth reading even for reports you are not going to rebuild. They routinely contain business rules that exist nowhere else in the organisation, because somebody needed a figure calculated a particular way and the report was the fastest place to put it.

Typical examples we find:

• How a margin is actually calculated, including which cost components are excluded
• Which customer or product categories are deliberately left out of a summary, and why
• Date logic for a financial period that does not match the calendar
• Rounding and tolerance rules applied before a figure is presented
• Exception cases hardcoded for a specific customer years ago

Step 4: rebuild and reconcile

For the live set, rebuild in whatever reporting tool suits where the data is going and who writes reports. The tool matters far less than the reconciliation.

Reconciliation means running the old report and the new one over the same period and comparing figure by figure until they agree. Not approximately, exactly. Reporting is the part of a migration the business checks first and trusts least, and a single unexplained variance will cost you more credibility than the whole rest of the project earns.

Keeping Crystal while you change the application

A useful and underused option: if the database structure survives the migration largely intact, the Crystal reports can keep running against it while the application is replaced. You then deal with reporting as a separate project afterwards.

This works when you are replacing the application layer and keeping the database. It does not work when the data model itself changes, which is the case in most true legacy migrations, so check early rather than assuming.

Either way the inventory comes first. It is a few days of work, it usually reduces the reporting scope by an order of magnitude, and it turns the one part of the project most likely to produce a nasty surprise into a known quantity before anybody commits to a number.