Infor VISUAL Performance Tuning: A Steering Committee Guide to Database, Application, and Cloud Optimization

Most executive teams find out their Infor VISUAL environment has a performance problem the same way: a plant manager reports that order entry is timing out during the morning shift change, or a controller notices that month end close now runs a full day longer than it did two years ago. By the time the issue reaches a steering committee agenda, it has usually been quietly eroding throughput for months. Performance tuning gets filed under IT maintenance, so it competes for budget against visible priorities like new functionality or headcount. That framing understates what is actually at stake.

A VISUAL environment sitting on a degraded SQL Server backend does not fail loudly. It fails as a slow accumulation of friction: work order entry that takes three seconds longer than it should, a Crystal Reports job that blocks live transactions during first shift, a batch process that creeps past its maintenance window and into production hours. None of those events triggers an incident report on their own, but together they compress the hours available for production, delay the financial close, and put audit readiness at risk during exactly the periods when the business can least afford it. For a discrete manufacturer running high transaction volumes, database performance is a direct input to production throughput, not a background concern for IT to manage on its own schedule.

This briefing walks through where VISUAL performance problems originate, what database, application, integration, and infrastructure level tuning look like in practice, and how to sequence a tuning engagement so it produces a measurable result rather than an open ended IT project. Organizations evaluating where this work fits into a broader Infor roadmap can also review our technical framework for successful Infor implementation, which covers the architecture and methodology decisions that shape performance outcomes from day one.

Where Infor VISUAL Performance Bottlenecks Actually Originate

Infor VISUAL is a multi tier application built on a Microsoft SQL Server transactional database, with the Infor VISUAL System Administrator’s Guide describing a system administered through a relational database management system that requires ongoing installation, configuration, and tuning discipline from a dedicated database administrator. VISUAL itself is a well engineered application layer, but its performance is only as good as the database tier underneath it, and that tier degrades quietly unless someone is actively managing it.

In practice, the majority of VISUAL slowdowns trace back to a small set of recurring causes. Index fragmentation builds up on high write tables such as work order headers, work order operations, and inventory transaction history as the business runs its daily volume of receipts, issues, moves, and labor postings. SQL Server’s query optimizer relies on statistics to estimate how many rows a query will touch, and when those statistics go stale relative to the actual data distribution, the optimizer starts choosing execution plans that scan far more data than necessary. Blocking and locking contention on those same tables becomes more frequent as concurrency increases, particularly when reporting or batch processes hold locks longer than they need to. Each mechanism is invisible to the end user until it crosses a threshold, at which point order entry, scheduling, and shipping all slow down at once because they share the same underlying tables.

Database-Level Tuning: The Foundation Layer

Index Strategy and Statistics Maintenance

Index strategy on a VISUAL database is not a one time setup task. As transaction volume grows and VISUAL is patched to new service packs, the query patterns hitting core tables change, and an index design correct at go live can become a liability two years later. A disciplined program rebuilds or reorganizes fragmented indexes on a defined cadence and refreshes statistics on the tables with the heaviest write volume, rather than relying on default auto update thresholds never tuned for a high transaction manufacturing workload. The business consequence is direct: every millisecond an index scan takes instead of an index seek is a millisecond added to work order entry, and multiplied across thousands of daily transactions, that adds up to real production time lost.

Tempdb Configuration

Tempdb is the SQL Server system database that handles sorting, temporary result sets, and version stores, and it is used constantly by VISUAL’s reporting queries, scheduling calculations, and batch jobs. AWS’s prescriptive guidance for running SQL Server on Amazon EC2 recommends isolating tempdb on its own high performance storage, using locally attached NVMe instance storage where available, separate from the data, log, and backup volumes. A poorly configured tempdb becomes a single point of contention that slows every concurrent user, so a small infrastructure change here can produce a system wide performance improvement that a business user actually feels.

Query Plan Regression from Infor Patch Updates

Infor releases service packs and patches to VISUAL on a regular cadence, and those updates can change underlying queries, stored procedures, or schema in ways that invalidate previously cached execution plans. When a plan regresses after a patch, a query that ran in under a second can suddenly take several seconds, and because the change is silent, it often gets misattributed to network issues or user error rather than the actual cause. A tuning discipline treats every VISUAL patch as a trigger to re-baseline query performance on the tables most affected, not just a functional testing exercise. For manufacturers running large scale data conversions alongside version upgrades, our guide to data migration strategy and tooling covers how to validate data integrity through that kind of transition.

Maintenance Plan Cadence

Backup jobs, index maintenance, statistics updates, and integrity checks all compete for the same database resources that live transactions need. A maintenance plan reasonable at a smaller data volume can start colliding with first shift order entry as the database grows, particularly at multi site manufacturers running near continuous production. The fix is rarely to eliminate maintenance tasks. It is to right size their frequency, scope them to the tables that actually need them, and schedule them against a documented production calendar rather than a generic overnight window that no longer reflects how the plant operates.

Application-Level Tuning: Where VISUAL Meets the Business

Configuring Uptime for VISUAL’s Database Tier

For manufacturers running VISUAL across multiple shifts or sites, the availability configuration of the underlying SQL Server instance becomes a production continuity issue rather than a pure IT concern. AWS’s reference architecture for SQL Server on Amazon EC2 separates the operating system, data, log, and tempdb volumes as a baseline, and layers in replication and failover options once that baseline is stable. The consequence of getting this wrong is straightforward: an unplanned database failover during a production shift stops every VISUAL user at once, from the shop floor to the shipping dock, until connections re-establish.

Report Generation Load: Crystal Reports and Birst

Crystal Reports jobs and Infor Birst dashboards are frequently the least visible source of VISUAL database load, because they run as read queries rather than transactions, but they can be more expensive than the transactions they report on. Infor’s own Birst documentation describes a Live Access capability that queries on premise data sources directly and in real time rather than through a pre-extracted data warehouse layer, meaning a poorly scoped Birst report can place the same load on VISUAL as a large batch job, without the visibility of one. Organizations running Infor Birst analytics against a live VISUAL database should treat report design as a database performance decision, scheduling heavy extracts against off peak windows and reserving Live Access queries for genuinely time sensitive views.

Batch Job Scheduling and Transaction Window Contention

Material requirements planning runs, invoice batches, and EDI processing jobs are often scheduled based on when someone set them up during implementation, not current transaction volume. As the business grows, those jobs increasingly overlap with the start of first shift or month end closing, and the resulting lock contention slows both the batch job and the live users competing for the same tables. Reviewing the batch schedule against the current production calendar, and staggering jobs touching the same core tables, is one of the highest return, lowest risk tuning activities available because it requires no infrastructure change, only a scheduling correction.

Integration-Layer Performance: ION as a Load Factor

Infor ION sits between VISUAL and the other systems a manufacturer runs, using ION Connect to move business documents between applications, as described in Infor’s own ION integration documentation. Requests from external consumers pass through an API Gateway that brokers and throttles that traffic before it reaches the target application. Every document flow configured in ION Desk and every API call routed through the gateway ultimately reads from or writes to the same VISUAL database that shop floor and office users work in. As manufacturers add connected systems, whether a CRM pulling order status, a supplier portal checking inventory, or a shop floor execution system posting transactions in real time, the cumulative API call volume becomes a load factor on the core database that is easy to underestimate because no single integration looks expensive in isolation. A performance review of the ION integration layer should treat document flow volume and API call frequency as first class inputs to database capacity planning, not a separate workstream reviewed independently of core VISUAL performance.

This is particularly relevant for manufacturers running Infor Factory Track on the shop floor, since real time labor, material, and work order transactions posted from mobile devices flow back into VISUAL continuously rather than in scheduled batches, adding a steady stream of small transactions on top of the office side workload that the database has to absorb without a corresponding relief in maintenance windows.

Cloud vs On-Premises: VISUAL Cloud on AWS

For manufacturers weighing VISUAL Cloud against an on-premises deployment, this decision usually sits inside a wider evaluation of where VISUAL fits within Infor’s CloudSuite platform strategy for the business as a whole, rather than as a standalone infrastructure choice.

Instance Sizing and Storage IOPS

Infor’s cloud platform is built on AWS infrastructure spanning ten AWS regions and twenty seven availability zones worldwide, according to Infor’s own resources on its AWS partnership published in December 2025, giving VISUAL Cloud customers a broad set of deployment options. Getting the underlying compute and storage sizing right still matters. AWS’s guidance on selecting EC2 instances for SQL Server workloads notes that moving to newer instance generations with buffer pool extension support can allow a downgrade from SQL Server Enterprise to Standard edition while improving performance, directly reducing licensing cost alongside the gain. On storage, AWS’s Amazon EBS documentation describes General Purpose SSD gp3 volumes as delivering single digit millisecond latency with a performance baseline that scales independently of volume size, while Provisioned IOPS io2 Block Express volumes target average latency under 500 microseconds for demanding, latency sensitive database workloads. Undersized storage IOPS on a VISUAL Cloud database translates directly into slower transaction posting on the shop floor, the kind of degradation that looks like an application problem but is actually an infrastructure sizing problem.

Network Latency for Multi-Site Manufacturers

Multi site manufacturers connecting several plants into a single VISUAL Cloud instance are sensitive to network latency in a way single site operations are not, because every transaction from a remote plant has to traverse the network to reach the database. AWS’s Direct Connect documentation describes a dedicated connection that keeps traffic on the AWS global network rather than the public internet, reducing the variability of unpredictable internet routing. AWS’s Well-Architected Framework guidance on hybrid networking notes that latency over the internet varies because of changing routes, while a dedicated connection provides consistent, low latency connectivity between a manufacturer’s sites and AWS. For a plant on a tight production schedule, the difference between consistent and variable latency is the difference between a scanner transaction that posts instantly and one that occasionally hangs for several seconds, which compounds into real throughput loss.

The Business Case: Downtime, Throughput, and Audit Risk

Executive sponsors evaluating a performance tuning investment are usually asking a version of the same question: what does doing nothing actually cost. An Infor commissioned Total Economic Impact study conducted by Forrester Consulting and published in June 2025 found that Infor CloudSuite’s standard service level agreement promises 99.7 percent uptime, and that interviewed manufacturing and distribution customers cited reduced downtime as a meaningful, if unquantified, benefit of a well architected cloud environment, alongside a modeled 114 percent return on investment for the composite organization in the study. Even a system architected for that level of availability only delivers it when the database tier underneath is tuned to perform within its design envelope, since a badly indexed or lock contended database can produce effective unavailability, in the form of timeouts and stalled transactions, well before the infrastructure itself goes down.

The throughput impact of unaddressed database bloat compounds rather than announcing itself. A work order entry screen taking two extra seconds per transaction does not look urgent in isolation, but across a shift with hundreds of transactions per user and dozens of concurrent users, that same two seconds becomes a measurable reduction in the transactions the business can process in a given production window. Reporting and MRP jobs that used to finish comfortably overnight and now run into first shift do not just slow the report, they compress the time planners and schedulers have to react before the day starts.

Performance tuning also functions as risk mitigation ahead of two predictable events: a financial or compliance audit, and a peak production cycle such as a seasonal ramp or a major customer launch. Audit windows demand that reports, reconciliations, and data extracts run reliably and on time, and a database already near its contention limits has no headroom to absorb that load without visible slowdowns. Peak production cycles are precisely when transaction volume is highest and the business can least tolerate an outage or a batch job overrunning into live hours. Addressing performance debt before either event, rather than during it, converts an unpredictable risk into a scheduled, controlled engagement.

How a Performance Tuning Engagement Is Sequenced

A structured VISUAL performance engagement follows a consistent sequence, and skipping steps to get to remediation faster is the most common reason tuning work fails to produce a lasting result.

The assessment phase establishes a factual baseline: current index fragmentation and statistics freshness on the highest volume tables, blocking and wait statistics over a representative production period, current tempdb and storage configuration, and a review of the batch and report schedule against actual production hours. This phase produces a prioritized list of findings ranked by business impact, not just technical severity.

The remediation phase addresses those findings in an order that manages risk, typically starting with low risk, high return changes such as batch rescheduling and index or statistics maintenance, before moving into higher impact changes like storage reconfiguration or availability architecture adjustments that require a maintenance window.

The validation phase re-measures the same metrics captured during assessment against a comparable production period, confirming the changes produced a measurable improvement rather than relying on anecdotal reports that things feel faster.

The monitoring phase establishes ongoing visibility, so fragmentation, statistics staleness, and blocking trends are caught again before they compound into a repeat of the original problem, rather than waiting for the next executive escalation to trigger another full assessment cycle.

Frequently Asked Questions

How long does a typical Infor VISUAL performance tuning engagement take?

Assessment typically takes one to two weeks depending on data volume and the number of sites involved. Remediation timelines vary by finding, but low risk changes like batch rescheduling and index maintenance can often be completed within the same engagement, while infrastructure or availability changes may require a separate planned maintenance window.

Does performance tuning require downtime for our VISUAL environment?

Most assessment and analysis work happens without user facing downtime, since it relies on reading database metrics rather than changing configuration. Some remediation steps, particularly storage or availability architecture changes, do require a scheduled maintenance window, planned and communicated in advance rather than done during production hours.

Is VISUAL Cloud on AWS performance tuning different from on-premises tuning?

The core database tuning principles, indexing, statistics, tempdb configuration, and query plan management, are the same in both environments because they are properties of the SQL Server engine itself. What changes in a VISUAL Cloud on AWS environment is the infrastructure layer, where instance sizing, storage IOPS, and network connectivity for multi site manufacturers become tuning variables that do not exist in the same way on premises.

How often should index and statistics maintenance run on a high volume VISUAL database?

There is no single correct interval, since it depends on transaction volume and which tables see the heaviest write activity. A common approach monitors fragmentation and statistics staleness continuously and triggers maintenance based on defined thresholds for the highest volume tables, rather than a fixed weekly or monthly schedule that runs maintenance too often on stable tables and not often enough on volatile ones.

Can performance tuning wait until after our next audit or peak production cycle?

It can, but that is generally the higher risk choice rather than the lower effort one. Audit windows and peak production cycles are exactly when transaction and reporting load is highest, meaning a database already near its contention limits has the least headroom to absorb that demand without visible slowdowns.