SyteLine 9 to CloudSuite Industrial 10 upgrade checklist

Short answer

The database conversion is Infor's tooling and your partner's job. What decides whether go-live is calm is everything custom: reports, forms, IDO extensions, stored procedures, background tasks, integrations and the spreadsheets that read the database. Inventory all of it first, retire what nobody uses, run a full test upgrade on a copy of production, then compare every surviving custom object's output against the old system before you set a cutover date. Most upgrade delays come from customizations found in the last two weeks.

What changes, in plain terms

The details depend on your exact starting and target releases, so read Infor's upgrade documentation for your path. The themes are consistent:

The platform moves forward. The Mongoose framework, web client and supported SQL Server and Windows versions all move on. Plan server and SQL Server work alongside the application upgrade.
The schema changes. Tables, columns and standard procedures change between versions. Anything custom that touches them needs re-testing.
Reporting direction changes. Infor's Reports Overview recommends Report-type forms and DataView-based reports for new custom reports, and describes custom SSRS reports as deprecated, though still supported. Crystal has been outside the standard reporting path since 8.03.
Customizations need re-validation. Form customizations, IDO extension classes and event handlers have to be checked, and sometimes rebuilt, against the new version.
If you're moving to multi-tenant cloud, direct SQL disappears entirely. See Reporting in CloudSuite Industrial without direct SQL.

The checklist

1. Inventory every customization

Object	Where to look	Record
Custom reports	Report forms, Background Task Definitions, the report server	Who uses it, last run, data source
Crystal reports	File shares, menus	Same, and flag them for conversion
Form customizations	Forms in Design Mode, customization records	What changed and why
IDO extensions and custom IDOs	The IDOs form, deployed assemblies	Methods and what calls them
Custom stored procedures, views, tables, triggers	SQL Server, custom name prefixes	What uses them
Background tasks	Background Task Definitions, `EXE` and `SP` types	What they run, schedule
Event handlers	Event Handlers form, especially copies of standard handlers	Active or not
Integrations	EDI, web store, warehouse, BI, file exports	Tables and IDOs they touch
Spreadsheets and BI	Logins connecting to the database	Owner and purpose

The Background Task Definitions guide and SQL table cheat sheet help with the technical side.

2. Retire before you migrate

For each item, ask: is it used, is it still needed, does a standard feature now do it? Every report or customization retired is one less to rebuild and test. Get the business owner to sign the retire list.

3. Run a test upgrade on a copy of production

Upgrade a recent copy of production in an isolated environment, following Infor's procedure for your path. Log every failure. Custom tables, procedures and triggers that clash with the new schema usually show up here. Plan for at least two test upgrades: one to learn, one to time.

4. Fix and convert in the test environment

Rebuild or adjust custom reports. Decide per report whether it becomes a Report-type form, a DataView, a modified standard report or a rebuilt SSRS report. See SyteLine reporting options.
Re-apply or rebuild form customizations and event handlers. Decide each FormSync keep-or-remove prompt from your customisation register, not on the day. See Why SyteLine form changes disappear.
Recompile and test IDO extensions against the new framework.
Update custom stored procedures and views for schema changes, and fix any joins missing site_ref while you're there.
Re-point integrations and test them end to end. Integrations that write straight to tables are the ones most likely to break. Moving them to the IDO layer is worth considering now. See Connecting external systems with the IDO REST API.

5. Compare output, not screens

For each surviving custom report and process, run old and new on the same data with the same parameters, and compare row counts, totals and a sample of individual records. Have the business owner sign off on the comparison. This is where most silent errors are caught.

6. Test the business, not just the objects

Run full process tests in the upgraded environment: order to cash, procure to pay, plan to produce, and month-end. Include printing, emailing and scheduled tasks, which are often missed until the first morning after go-live. See How to schedule a SyteLine report.

7. Plan the cutover

Time the final upgrade from your test runs, agree a freeze, and write a step-by-step cutover plan with a rollback point. See the SyteLine go-live and cutover checklist.

How long the custom part takes

It depends almost entirely on step 1. A site with 20 custom reports and a few form changes is a short project. A site with 200 reports, Crystal, several integrations and undocumented SQL jobs needs months of work on customizations, regardless of how fast the database converts. Inventory first, then plan.

FAQ

What's the hardest part of a SyteLine 9 to 10 upgrade?

Usually the customizations: custom reports, form changes, IDO extensions, stored procedures and integrations, rather than the database conversion itself.

Do custom SyteLine reports work after an upgrade?

Some do, many need changes. Re-test every custom report against the upgraded database, and compare output with the old system.

Should we convert Crystal reports during the upgrade?

Yes, if they're still used. Inventory them, retire the unused ones, and rebuild the rest as Report-type forms, DataViews or SSRS reports.

How many test upgrades should we run?

At least two: one to find problems, and one to rehearse and time the real cutover.