✅ OasisPro · Crystal Reports Compatibility Checklist · IFS Cloud 26R2
Test before you decide.
6 essential things to get right.
Crystal Reports compatibility checklist testing is the difference between a rebuild estimate that holds and one that quietly doubles halfway through the project. Not every report in your estate carries the same risk. Some are straightforward regardless of which route you take. Others hinge on specific Crystal Reports mechanics that behave very differently depending on whether you rebuild or preserve.
This Crystal Reports compatibility checklist is the six things worth checking on every report that survives your estate audit, before you commit that specific report to a route.
None of it requires specialist tools, expensive software, a formal audit team, or deep Crystal Reports development experience to carry out properly and consistently.
It requires opening each report in turn and looking carefully for six specific, well-defined technical things, one at a time and methodically.
That is genuinely all it takes.
A report with none of these six features is low risk whichever route you choose. A report with three or more of them is exactly where rebuild estimates go wrong, and exactly where preservation earns its keep.
The checklist is not about finding reasons to avoid rebuilding. Plenty of reports genuinely are simple, and Report Studio handles them well. The value is in identifying, before you commit to a specific route, which reports are not simple, so the harder ten percent of your estate gets planned for honestly and specifically, rather than discovered halfway through a project already under way.
The 6 things on the Crystal Reports compatibility checklist
- 1. Subreports, nested or linked. Each one needs individual translation and testing under rebuild, and is where estimates most often run long. Preservation carries them across exactly as they behave today.
- 2. Cross-tab layouts. Cross-tabs have no direct one-to-one equivalent in Report Studio and typically need restructuring rather than translation, which is meaningfully more effort than a standard tabular layout.
- 3. Custom formulas and conditional logic. Anything beyond basic arithmetic, particularly conditional formatting or derived fields, has to be rewritten by hand and checked against the original result.
- 4. Embedded images and dynamic graphics. Logos, signatures, or images that change based on data need their source and placement checked, since image handling differs between the two platforms.
- 5. External data connections. Reports pulling from anything outside the core IFS database, another system or an external file, need that specific connection path tested, not assumed to carry over automatically.
- 6. Parameter fields and prompts. User-entered parameters that shape the report at run time need their prompts, validation and defaults checked individually, since parameter handling is one of the more fiddly translations in practice.
Zero or one feature present
Low risk under either route. These reports are strong candidates for rebuilding in Report Studio if you are pursuing a mixed strategy, since the effort is genuinely close to a straightforward translation.
Two features present
Worth budgeting extra time for under rebuild. Not necessarily a reason to preserve rather than rebuild, but a reason to test thoroughly and not assume the flat per-report estimate will hold.
Three or more features present
These are the reports where preservation most clearly earns its cost. Rebuilding them properly is genuinely expensive, and CrystalWorks removes that cost entirely by keeping the original file running unchanged.
Why this checklist matters more than the report count
Two estates of exactly the same overall size can have wildly different real effort depending on how many individual reports trigger three or more items on this checklist. A hundred reports with none of these features is a lighter project than forty reports carrying most of them. Count by risk, not just by volume, before costing anything.
Using the Crystal Reports compatibility checklist properly
Treat the Crystal Reports compatibility checklist score as a starting point for a conversation about the Crystal Reports compatibility checklist findings, not as a final verdict.
Run it against every report that survives your estate audit, not the full registered count, since dormant reports awaiting retirement do not need testing at all before they are simply removed.
Score each surviving report on how many of the six checklist features it genuinely contains, and use that score consistently to split the whole estate into low, medium and high risk groups.
Share the scored list with whoever owns the reporting decision, not just with the technical team doing the testing, so the business understands exactly where the real cost and risk sit before a route is chosen.
Cost the high-risk group separately, since a flat day rate applied evenly across the whole estate will understate exactly the reports most likely to overrun.
Revisit the checklist if a report's business purpose changes. A simple extract that later gets a customer-facing cross-tab bolted onto it moves risk tiers,
and the original low-risk assessment stops being accurate the moment that change lands.
The IFS documentation site covers Report Studio's supported layout and formula capabilities in real technical detail, genuinely useful for confirming exactly where a specific tricky feature lands.
The IFS Community has active threads on specific subreport and cross-tab translation patterns that go beyond what the official documentation covers.
Our own Report Studio requirements guide covers exactly what rebuilding actually involves once a given report clears this checklist cleanly.
Not every report carries the same risk. Test before you cost, and the estimate you end up with will actually survive contact with the project.
Building the checklist into your Crystal Reports estate audit
Run this checklist as the final stage of your estate audit, once dormant reports are already retired, so you are only scoring the ones actually worth deciding on.
Record the score alongside the report in whatever tracker you are using, so the risk tier travels with the report through every later conversation.
For the high-risk group, CrystalWorks removes the question entirely.
Every feature on this checklist behaves identically under CrystalWorks, because the report itself does not change. Subreports, cross-tabs, custom formulas and external connections all keep working exactly as they do today, with nothing to rebuild and nothing to reconcile.
Start with an estate audit to find your high-risk reportsGet your estate scored against this checklist.
Send us your surviving report list. We will score each one against all six compatibility factors and return a risk-tiered breakdown you can use to decide, report by report, which route makes sense.
Do all Crystal Reports features work the same after IFS Cloud 26R2?
It depends entirely on which route you take. Reports preserved through CrystalWorks keep every feature exactly as it behaves today, because the original .rpt file runs unchanged. Reports rebuilt in Report Studio need every feature individually recreated, and some Crystal Reports specific mechanics have no direct equivalent.
Are subreports a problem for Crystal Reports compatibility?
They are the single most common source of underestimated effort in a rebuild. Nested or linked subreports need their own translation and their own testing in Report Studio. Under preservation with CrystalWorks, subreports behave exactly as they always have, since nothing about the report changes.
What about Crystal Reports with external data connections?
Reports pulling from data sources outside the core IFS database, such as an external file, spreadsheet or a wholly separate system, need that connection path checked specifically and individually. Preservation keeps the original connection working as before. Rebuilding requires establishing an equivalent data path through an OData projection, which is not always straightforward.
How do I know which of my reports need close attention before 26R2?
Run each report through this checklist: subreports, cross-tabs, custom formulas, embedded images, external connections, and parameter fields. Reports triggering several of these are the ones worth testing most carefully, or the strongest candidates for preservation rather than rebuild.
A Crystal Reports compatibility checklist turns a guess into a plan
None of the Crystal Reports compatibility checklist itself takes especially long to run through, and all of it makes the eventual final decision genuinely defensible.
Six things, checked on every report that matters: subreports, cross-tabs, formulas, embedded images, external connections and parameters.
Reports with none of them are safe under either route you eventually choose.
Reports with several are exactly where an honest, evidence-based decision between rebuilding and preserving actually gets made rather than simply assumed.
Test first, and the route you choose will be the right one for the right reasons.