Infor SyteLineFree checklistPDF, Excel, Word exportInfor SyteLineAll Infor SyteLine (CloudSuite Industrial) tools

SyteLine SQL Server Version Upgrade Checklist

This checklist covers upgrading the SQL Server instance under an on-prem SyteLine 9 or 10 system, in place or by moving to a new server side by side. It covers the SQL Server work and the SyteLine application tier steps that DBAs often miss.

0%

0 of 35 items complete

13 critical items still open - these are the highest-risk gaps.

Download checklist:

Compatibility

Before the move

The move

Reconnect the application tier

Validate

After go-live

Count the critical items still open. Do not start the cutover with open critical items in Compatibility or Before the move; those are the ones that cannot be fixed afterwards without a rollback.

Get your SQL Server move plan reviewed

Send your current and target SQL Server versions, database list and multi-site layout and we will review the plan and the reconnect steps.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

In place or side by side

An in-place upgrade runs SQL Server setup over the existing instance. It keeps names and logins but leaves no easy rollback once it starts. A side-by-side move installs the new version on a new server or instance and restores the databases there. It needs more preparation, logins, jobs, linked servers and report server keys, but the old server stays untouched as a rollback until you decide to retire it. For an ERP that the plant runs on, side by side is the usual choice. Either way, confirm first that your SyteLine release supports the target SQL Server version: check Infor's system requirements for your exact release and do not rely on general SQL Server compatibility.

SQL Server details that break SyteLine

Collation must match the original exactly; a different server collation causes errors when SyteLine code joins temp tables to application tables. Logins must be moved with their SIDs so database users map without becoming orphans; sp_help_revlogin from Microsoft is the usual tool. SQL Server Agent must be running for the backup and maintenance jobs you moved. Restore databases at their old compatibility level first and raise it only after testing, since the newer cardinality estimator can change plans for heavy SyteLine queries. Multi-site setups spread across servers often rely on linked servers, which must be re-created with the same names and security.

  • Collation identical to the original
  • Logins moved with SIDs, orphaned users fixed
  • SQL Server Agent running
  • Compatibility level raised only after testing

Reconnecting SyteLine to the new server

SyteLine does not find the new server on its own. Configuration Manager holds the configurations that map users to databases; update each to the new server and database names. Service Configuration Manager holds the TaskMan, replication and event service settings; update those too, then restart the IDO Runtime Service and the other services. Point report server data sources at the new server. If SSRS moved, restore its encryption key on the new report server or stored credentials and subscriptions will not work. Check that ION still reaches the outbox. Then use LogMonitor while users open forms to catch any connection still pointing at the old name.

How to validate before handing back

Run a short script of checks at every site: log in, open key forms, run one report through TaskMan and see it in Background Task History, post and reverse a controlled transaction, and check replication and BOD flow. Read the SQL Server error log and LogMonitor. In the first week, compare wait statistics and slow queries with a baseline taken on the old server; plan regressions usually show up in large reports and MRP. Update statistics and run index maintenance soon after the move. Keep the old server until a full month-end close has run on the new one.

Frequently Asked Questions

How do I upgrade SQL Server for an ERP database?

Confirm the ERP release supports the target version, back up everything, then either upgrade in place or install the new version side by side and restore the databases. Move logins with SIDs, jobs and linked servers, keep the old compatibility level at first, reconnect the application tier and validate with real transactions before go-live.

Which SQL Server versions does SyteLine support?

It depends on your exact SyteLine or CSI release and changes as Infor certifies new versions. Check the system requirements document for your release on Infor's documentation or support portal. Do not upgrade SQL Server beyond what your release lists, even if the database restores without errors.

What is the safest way to upgrade Microsoft SQL Server?

Side by side: install the new version on a new server or instance, restore the databases, move logins, jobs and keys, and test before switching users over. The old server stays as a rollback. In-place upgrades are faster but leave no simple way back once setup starts.

Should I change the compatibility level after upgrading SQL Server?

Not immediately. Keep the old compatibility level after the move, confirm everything works, then raise it in a test environment and compare plans for heavy queries. A newer level can change the cardinality estimator and query plans, which can slow some large reports even as others improve.

If you want your team to ask SyteLine questions in plain English on the new server, we can add a private AI layer on your own infrastructure with read-only access.

ArchRay builder
Design the on-prem AI stack for Infor SyteLine: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Guides

Integrations

Software