Reporting
Moving off Crystal Reports in SyteLine: retire, replace, or rebuild as a Report-type form
Applies to: SyteLine shops upgrading from 8.02 or earlier, or still running custom Crystal Reports on later versions, including moves to CloudSuite Industrial
Short answer
Don't start by converting files. Find out which Crystal reports are still used, retire the rest, and check whether a standard report or a DataView already covers each survivor. For what's left, rebuild the data logic first, then build the layout as a Report-type form. That's Infor's current recommendation for new custom reports, because Infor now describes custom SSRS reports as deprecated (still supported, but not the route for new work). Prove the new report matches the old one on the same data before anyone switches over. Automatic Crystal-to-SSRS converters exist, but they produce a deprecated format and don't carry formulas or SQL commands over reliably, so they're rarely the shortcut they look like.
Why this keeps coming up
SyteLine's standard reports moved from Crystal Reports to SQL Server Reporting Services at version 8.03. Many businesses upgraded past that point and kept their custom Crystal reports running alongside. They work, until an upgrade, a server change, a move to cloud, or the one person who understood them leaves. Then they become urgent.
Infor's direction has since moved on again. Its Reports Overview describes custom SSRS reports as deprecated and recommends Report type forms or DataView-based reports for new custom reports. Rebuilding Crystal reports in SSRS today means rebuilding them in a tool you'll probably move off later.
Choose the target for each report
| If the report is… | Move it to | Why |
|---|---|---|
| Unused, or a duplicate of another | Retire it | Cheapest option, and no maintenance |
| Covered by a standard report with different options | The standard report | Supported by Infor through upgrades |
| A list people filter, sort and export | A DataView | Users can adjust it themselves |
| A fixed-layout document (customer-facing, printed, scheduled) | A Report-type form | Infor's recommended route for new custom reports |
| Very complex, and you already run a mature SSRS library on-premises | SSRS, as a deliberate exception | Supported, but deprecated. Document why, and plan to revisit |
Phase 1: Inventory, then cut
List every custom Crystal report with:
| Column | Why |
|---|---|
| Report name and file | So you can find it |
| Who uses it, and how often | Unused reports don't get migrated |
| What it's for, in one line | Helps spot duplicates |
| Data source (tables, views, stored procedures, SQL commands) | Drives the effort estimate |
| Special features (sub-reports, running totals, formulas, barcodes) | The parts that need the most work |
Then cut hard. In most report libraries a large share of reports haven't been run in a year, or duplicate another with a different sort. Every report you retire is one you don't rebuild, test or maintain. Get the business owner to sign off on the retire list.
Phase 2: Check standard reports and DataViews first
For each survivor, ask two questions:
- Does a standard report, with different options, already do this? Many custom Crystal reports were written before the standard report could do the job, or because nobody knew it could.
- Is it really a report? A list people export to Excel is often better as a DataView. See SyteLine reporting options.
Only what's left goes on to a rebuild.
Phase 3: Rebuild the data logic first
This is where the real work is, and where conversion tools help least.
- Pull the logic out of the report. Crystal reports hide business logic in formulas, record selection formulas, running totals and SQL Command objects. Write down what each one does in plain language.
- Give it a home in the data layer. For a Report-type form, the data comes through IDOs. Where the existing IDOs don't give you what you need, the usual options are a stored procedure exposed through a custom load method on an IDO, or a custom IDO over a view. Logic in one tested place survives any layout redesign.
- Fix it while you're there. Join on
site_refas well as the business key, avoid functions wrapped around filtered columns, and replace row-by-row logic with set-based queries. See Why your SyteLine report is slow. - Test the data on its own against the Crystal report's output before building any layout.
Phase 4: Build the layout as a Report-type form
- Build the form in Design Mode, or the Web Designer in the web client. Infor also provides a Report Builder wizard for creating report forms.
- The form is the report template: header regions, the detail data, footer regions, and standard values such as company name, logo and page numbers.
- Users click Run to generate the pages and Export to produce the PDF.
- Match the old layout only where it matters: customer-facing documents, forms that are filed or scanned, labels that must fit the stock. Internal reports can usually be simplified.
Save the form at Site scope (or the right Group), not your own User scope. See Why SyteLine form changes disappear.
Phase 5: Make it run like any other report
- Schedule it if it's needed regularly. A Report-type form can run as a background task: Mongoose runs it as the submitting user and publishes the output to a set destination. See How to schedule a SyteLine report or utility.
- Put it where users look, on the menu or folder where the Crystal report used to be.
- Add it to your register of customised forms, so upgrades don't surprise you.
Phase 6: Prove it matches
Run old and new on the same data, with the same parameters, and compare:
- row counts and grand totals
- a handful of records picked at random, plus the awkward ones: credits, zero quantities, multi-currency, multi-site
- page breaks and layout for anything printed or sent externally
Have the business owner sign off on the comparison, not on a demo. Keep the results with the ticket.
Phase 7: Switch over and retire
- For financial reports, run both side by side for one period, such as one month-end.
- Move menus, schedules and user habits to the new report.
- Remove the Crystal version from use, and archive the file for reference.
A realistic effort guide
| Report type | Typical effort per report |
|---|---|
| Retire, or replace with a standard report | Very low |
| Simple list that becomes a DataView | Low |
| Grouped report with totals and a few formulas | Medium |
| Customer-facing document with exact layout | Medium to high |
| Sub-reports, SQL commands, heavy formula logic | High |
The inventory and retire steps usually cut the total effort more than any conversion tool does.
FAQ
What should replace Crystal Reports in SyteLine?
Retire what isn't used, then use standard reports, DataViews for lists, and Report-type forms for new fixed-layout documents. Infor recommends Report type forms or DataView-based reports for new custom reports.
Should I convert SyteLine Crystal Reports to SSRS?
Usually not for new work. Infor now describes custom SSRS reports as deprecated, though still supported. Converting to SSRS can make sense only as a documented exception where you already run a mature SSRS library.
When did SyteLine switch from Crystal Reports to SSRS?
At version 8.03. Versions 8.02 and earlier used Crystal Reports for standard reports.
What's the hardest part of moving off Crystal?
The business logic hidden in formulas and SQL commands, not the layout. Write it down and rebuild it in the data layer first.