Clear Cutover Get a quote

Upgrades

10 Questions to Ask Before You Upgrade SyteLine

Applies to: SyteLine / CloudSuite Industrial 9.x and 10.x

Short answer

Before you upgrade SyteLine (Infor CloudSuite Industrial), you should be able to answer ten practical questions: what you run today, where you are going and why, what is customized, what connects to the system, how you will test, when you will cut over, what users must learn, how you would back out, and who owns the project. Most upgrade trouble comes from questions nobody asked early enough, not from the software itself.

  • Know your starting point: Version, deployment model, and every customization.
  • Know your destination: Target version, and whether hosting changes too.
  • List every connection: Barcode, shipping, EDI, reporting, payroll, and anything else.
  • Test with real users and recent data: IT cannot tell you whether a planner's day still works.
  • Plan the cutover and the way back: Pick the date deliberately and agree rollback conditions in advance.

1. What Exactly Are We Running Today?

Write down the version, the deployment (your own servers, hosted, or Infor's cloud), and when you last upgraded. Plenty of teams find during planning that nobody is quite sure. If the product name itself is causing confusion, read SyteLine vs CloudSuite Industrial.

2. What Is the Target, and Why?

"We're behind" is not a reason. Name the specific goal: continued support, a feature, a hosting change, a security requirement. A clear reason helps you say no to scope creep later.

3. What Is Customized, and Who Built It?

List every customization with its owner and purpose. In SyteLine that usually means:

  • User-defined fields and form personalizations (user, group, and site level)
  • Event handlers and Application Event System workflows
  • IDO extension classes and custom IDOs
  • Custom or modified reports
  • Anything made directly in the database: triggers, stored procedures, or table changes

Changes made with the supported framework tools usually move to a new version more easily than direct database changes, but every one still needs testing. An upgrade is also the best moment to retire customizations nobody uses. Customize or configure explains how to keep that list under control.

4. What Connects to SyteLine?

Barcode and data collection, shipping software, EDI, reporting tools, a website, payroll. Each connection is a place an upgrade can quietly break something. Give each one an owner and get a clear answer on whether it supports the target version.

5. Do We Have a Realistic Test Copy?

A test system with stale or tiny data hides problems. Use a recent copy of live data so people can run real scenarios, and know who can refresh it and how long that takes.

6. Who Will Test, and What Will They Test?

Choose real users: a planner, a buyer, a shipping clerk, an accountant. Give them real tasks: enter an order, release a job, report labor, receive a purchase order, ship, invoice, close jobs, and run month-end reports. Checking that each screen opens is not testing.

7. When Is the Cutover, and What Else Is Happening?

Avoid month-end, quarter-end, year-end, physical inventory, and peak shipping weeks. Review the month-end close checklist with accounting before you pick a date.

8. What Will Users Need to Learn?

Even a same-product upgrade can move buttons and change screens. Plan short, role-based sessions close to go-live, and tell people early what will look different.

9. What Is the Rollback Plan?

Decide in advance what would make you stop, who decides, and what going back involves. If rolling back becomes impossible after a certain point, everyone should know exactly when that point is.

10. Who Owns This, Day to Day?

Every upgrade needs one person who can make decisions and chase answers. If it is everyone's job, it is nobody's. Make sure that person and the testers have real time set aside, because upgrades rarely fit into spare time.

A Composite Example

This is a composite of a pattern that comes up often, not a single client.

A metal fabricator schedules its upgrade for the last week of the fiscal year, because IT expects things to be quiet. But accounting needs that week to close the year, and the people who should be testing are busy with year-end. Testing is rushed, nobody checks a barcode integration, and go-live is shaky.

Moving the date a few weeks and naming an owner for integrations would have cost almost nothing. The calendar and the connections caused more trouble than the software.

Pre-Upgrade Checklist

  • Current version, deployment, and target written down
  • A specific reason for upgrading
  • Every customization listed with an owner
  • Every integration has an owner and a compatibility answer
  • Test copy uses recent data
  • Real users have real test scripts
  • Cutover date avoids close and peak periods
  • Rollback conditions agreed
  • One named project owner with time to do it

FAQ

How long does a SyteLine upgrade take?

It depends on the number of customizations and integrations, how much testing you do, and how much data you carry. Ask your implementer for a range based on your own system rather than a general figure.

Should we upgrade and move to the cloud at the same time?

You can, but it combines two changes. Many teams separate them so problems are easier to diagnose. If you combine them, allow extra testing time.

Do we need to retrain everyone?

Usually a focused refresher works better than full retraining. Concentrate on the screens and processes that changed for each role.

What is the biggest upgrade risk?

In our view, customizations and integrations that nobody listed. They are rarely hard to fix, but they are expensive to discover late.

If you are planning an upgrade and want a second opinion on what you might be missing, ClearCutOver can review your customization and integration list with you.

ClearCutOver is an independent SyteLine resource and is not affiliated with Infor. Infor, SyteLine, and CloudSuite are trademarks of Infor.

Systems I work on