Why SyteLine upgrades go sideways
- Undocumented customizations — the report someone built in 2011 that the CFO still opens every Monday.
- Direct-SQL modifications that bypass the IDO layer and break silently on the new schema.
- Integration assumptions — external systems coded against version-specific behavior.
- Testing by hope — no regression inventory, so testing covers what people remember, not what exists.
Phase 1: Inventory everything (weeks, not months)
Before scoping anything, produce a complete inventory: custom forms, IDO extensions, stored procedures, event handlers, reports, scheduled tasks, and integrations. For each item you need three facts — does it deviate from stock, is it still used, and what does it touch?
This is where AI tooling collapses the timeline. SyteRay's migration agents (Impact Analyzer, Compatibility Checker, Data Mapper) scan your installation and produce the inventory automatically: every customization, its usage, and its version-compatibility risk, ranked. What used to be a three-month consulting discovery becomes a first-week deliverable your team and your partner can work from together.
Phase 2: Decide — carry, rebuild, or retire
The retire column is the hidden win. Shops routinely discover a third or more of their customizations exist only because nobody was sure it was safe to remove them. Usage data turns that fear into a delete key.
| Category | Action | Typical share |
|---|---|---|
| Still used, IDO-clean | Carry forward with light testing | ~40% |
| Still used, direct-SQL or fragile | Rebuild properly in an isolated namespace | ~20% |
| Unused or superseded by new stock features | Retire — delete with confidence | ~40% |
Phase 3: Rebuild upgrade-safe
Everything you rebuild should land in an isolated extension namespace, bound to IDOs, never touching core objects — so this upgrade is the last painful one. SyteRay's extension workflow enforces this by construction: generated logic lives in slx.*, deploys through the policy engine, and carries its own documentation and audit trail.
Phase 4: Test against reality
Your regression suite is the Phase 1 inventory, not people's memories. Test the carried customizations, replay integration flows with production-shaped data, and run the old and new environments in parallel through at least one full close cycle before cutover.
Frequently asked questions
How long does a SyteLine upgrade take?
Anywhere from three months to over a year — the spread is almost entirely explained by customization debt and how early it gets inventoried. Automating the discovery phase is the single biggest accelerator.
Should I move to cloud CSI or stay on-premise when upgrading?
It depends on compliance and control needs. ITAR/CMMC shops usually stay on-premise (CSI supports this); others weigh Infor-managed infrastructure against customization flexibility. The upgrade playbook is the same either way.
Can SyteRay help with a SyteLine upgrade?
Yes — its migration agents automate the inventory and risk-mapping phases: Impact Analyzer maps customizations, Compatibility Checker flags version deltas, and Data Mapper handles field mapping. Your team or your implementation partner then works from a ranked, factual work plan.
Do I lose my customizations when upgrading SyteLine?
Not if they're built correctly. IDO-based extensions in an isolated namespace carry forward cleanly. Direct-SQL customizations are the ones at risk — identify them early and rebuild them properly.
Know your upgrade risk before you scope it
Run SyteRay's migration agents against your installation and get a ranked customization inventory in days.