Report conversion is usually treated as the boring part of a Kinetic project. It is where a surprising amount of the risk lives, because a report estate is the part of the system users touch most and understand least.
Triage before you convert
Not every report deserves to survive. Before writing a single BAQ, inventory what exists and disposition each one:
- Convert: genuinely used and still correct
- Rebuild: needed, but the current version is wrong or unmaintainable
- Retire: nobody has run it in a year, or it duplicates another report
That last category is always bigger than the client expects. Reports accumulate. Somebody needed a variant once, it got saved, and it has been sitting in the menu ever since. Converting it costs real money and delivers nothing.
The inventory is also the moment to find duplicates. Two reports with slightly different names that hit the same underlying data are common, and matching on the target they report against finds pairs that name-matching misses.
Audit the formulas on the way over
This is the part that gets skipped, and it is the part that matters.
A Crystal report that has been in production for years is assumed correct because it has been running for years. Those are different things. Latent defects survive indefinitely when the condition that triggers them is rare, and a conversion is the one time somebody is reading the formula closely enough to notice.
Read every calculated field. Ask what it assumes. Where a formula derives a value indirectly, check whether the direct value is available, because indirect derivations are where the wrong answers live.
If you find a defect, say so before you convert. Fixing it during conversion is cheap. Fixing it after go-live is a support ticket and a credibility problem.
The menu problem
Here is a failure mode specific to Kinetic conversions, and it wastes days.
You convert the reports. You build the new menu entries. The client reports that the reports are still broken, or missing, or unchanged.
Check which menu they are actually clicking. Classic menu entries frequently survive a conversion project, sitting in the tree alongside the new ones. Users click the path they have clicked for years. They are running the old report and telling you the new one is broken.
A quick way to tell the two apart: working entries built for the modern UI carry a distinguishing argument that the classic ones do not. Enumerate the menu programmatically rather than clicking through it, and the duplicates become obvious immediately. It is common to find dozens of classic-only entries still live in a tenant.
Retiring the old menu entries is part of the conversion. A conversion that leaves both paths in place has not finished, it has just added ambiguity.
Security is rarely the answer
When a report errors for one group of users and works for another, the theory that forms immediately is a permissions problem. Check it, because it is quick, but check it properly across every layer: the query definition, the report definition, and the menu entry.
In practice this theory is usually wrong. Verify it and move on rather than letting it consume the investigation, because while you are chasing security the real cause is usually something structural about which entry is being invoked.
What good looks like
A finished report conversion has:
- an inventory with a disposition on every report and the retirements actually executed
- formula audit notes on each converted report, including any defect found
- the classic menu entries removed, not merely superseded
- each converted report verified against a known document or period, with the comparison recorded
Without that last one you have a report that renders. Rendering is not the same as correct.