🔌 OasisPro · Data Source Migration · IFS Cloud 26R2
The connection string doesn't exist anymore.
Crystal Reports data source migration is the part of a rebuild that happens before a single formula or layout decision, and it's the part most estimates skip entirely. Every report connects to data somehow, and that connection method itself is changing, not just the reporting tool sitting on top of it.
A report built against a direct table or view reference doesn't automatically know how to talk to an OData projection instead. That's not a formula fix or a layout fix. It's a completely different data access method, and it has to be resolved before anything else about the report can be trusted.
Here are the 6 things that change underneath a Crystal Reports data source migration, feeding into IFS Cloud.
Rebuilding a report's formulas and layout assumes the report can actually reach its data in the first place. That assumption is exactly what a data source migration breaks, and it breaks before any other part of the rebuild even starts.
This is the least visible part of a migration and often the most foundational. Get the data connection wrong and every other fix on top of it is built on sand.
The 6 things Crystal Reports data source migration changes underneath
- 1. Direct table or view access versus OData projections. Reports referencing IFS Cloud data structures directly don't carry over cleanly into the Projections and OData model most modern reporting relies on. That's remapping work, not a formula fix.
- 2. Field name and type mapping. A field that existed under one name or data type in the old data structure may be named, typed or located differently in the new one, and every formula or filter referencing it needs to follow that change.
- 3. Custom SQL command-based reports. Reports built on hand-written SQL commands inside Crystal Reports need that logic rebuilt against the new data access layer entirely, since raw SQL commands rarely have a direct equivalent.
- 4. Stored procedure-based reports. Reports pulling data through a stored procedure need that procedure's logic re-evaluated against what's actually available and callable in the new environment, not assumed to carry over unchanged.
- 5. Refresh and caching behavior. How and when a report's data actually refreshes can differ between the old and new data access methods, which affects whether users are seeing live or stale data without realizing it.
- 6. The security context of the connection. Who or what a report's data connection runs as determines what data it can actually see, and that context needs to be matched to the new Projections and Actions permission model, not assumed to inherit automatically.
Why direct table references need full remapping
A report that queries a table directly has no automatic path to an OData projection. Someone has to build that path deliberately, report by report.
Why custom SQL and stored procedures cost the most
These represent hand-written logic with no equivalent to inherit. They need to be re-evaluated and often rebuilt from scratch against what the new data layer actually exposes.
Why security context ties straight into PermissionWorks
A migrated report's data connection needs access rules matched to the new Projections and Actions model, or it either sees too much data or breaks trying to see any.
The check that should happen before any rebuild work starts
Confirm what data access method each surviving report actually uses today: direct table reference, custom SQL command, stored procedure, or something else. This single check tells you which reports need a straightforward remap and which need a full rebuild of their data logic.
How this connects to the rest of your migration
This is foundational work, and it belongs in the estate audit alongside complexity triage, not treated as a separate, later step.
A report's formulas and layout can be perfectly rebuilt and still fail entirely if its underlying data connection was never properly remapped.
The security context question connects directly to PermissionWorks, since a report's data access needs to respect the same Projections and Actions model governing everything else a user can do.
A rebuilt formula on top of a broken data connection isn't fixed. It's decoration on a report that can't actually reach its data.
What getting this wrong actually costs
A report rebuilt with correct formulas and layout that still fails entirely, because nobody checked whether its underlying data connection had a real path in the new environment.
A custom SQL command-based report discovered mid-project to need a complete rebuild, after it was quoted and scheduled like a straightforward remap.
A security context mismatch that lets a report see data it shouldn't, or nothing at all, discovered only when someone notices the output doesn't match expectations.
We'll check your data source category before you quote anything.
OasisPro identifies which reports use direct table access, custom SQL commands, or stored procedures, so your rebuild estimate reflects the real underlying work, not just formula and layout complexity.
Start with the Crystal Reports estate auditKnow your data source risk before you quote the rebuild.
Send us your report registry and we'll categorize which reports use direct access, SQL commands or stored procedures, so your estimate reflects the real underlying work.
Why does the data source matter separately from the report's formulas or layout?
Because a report's connection to its underlying data is a completely different concern from its formulas or layout. A report can have perfectly rebuilt logic and still fail entirely if its data connection was never properly remapped to the new data access method.
Which reports need the most rework on their data source specifically?
Reports built on custom SQL commands or stored procedures inside Crystal Reports. That hand-written logic rarely has a direct equivalent and often needs to be rebuilt from scratch against the new data layer.
How does this connect to security and permissions?
A report's data connection has a security context determining what data it can actually see. That context needs to be matched to the new Projections and Actions permission model, not assumed to carry over automatically.
Should data source migration be checked before or after formula rebuilding?
Before. A report's data connection is the foundation everything else depends on, and checking it early tells you which reports need a straightforward remap versus a full rebuild of their underlying data logic.
Check the connection before you trust the report
A Crystal Reports migration isn't just a formula and layout exercise. The ground underneath every report, how it actually reaches its data, is changing too, and that has to be checked first.
Six things, all of them foundational. Get the data source right before anything built on top of it can be trusted.