We’re evaluating a move from on-premise to CloudSuite ICS 2022 for our asset management operations. I’m particularly interested in understanding real-world performance differences for batch processing jobs.
Our current on-premise setup processes about 50,000 asset records nightly for depreciation calculations, maintenance scheduling, and compliance reporting. This typically completes in 2-3 hours. I’m curious about others’ experiences with similar workloads in the cloud-does network latency impact batch job performance? How does cloud scaling help with resource-intensive processes?
What performance characteristics should we expect, and are there specific optimizations that work better in cloud versus on-premise?
Batch throughput regressions during cloud migration are a known risk for asset-intensive workloads, typically driven by I/O contention, scheduler configuration mismatches, and multi-tenant resource ceilings rather than network latency (batch jobs run server-side, so WAN latency is largely irrelevant).
Diagnostic Steps
Baseline your on-premise job with ION Grid monitoring active — capture CPU, heap, DB connection pool utilization, and elapsed time per job step (depreciation calc, maintenance scheduling, compliance extract separately).
In CloudSuite, locate batch job configuration under Infor OS > ION > Job Scheduler and confirm your depreciation batch is assigned to a dedicated Grid Node worker pool, not shared with interactive sessions.
Review SCS (Sunsystems/CloudSuite) batch job chunking parameters — 50,000 records processed as a single commit set will thrash rollback segments; verify chunk/page size is set appropriately (see below).
Check DB connection pool sizing in Grid Management Console. Cloud deployments default conservatively — verify in your version, but pool starvation is a common bottleneck at this record volume.
Confirm Landmark Grid thread concurrency settings; cloud environments allow horizontal scaling via node count, which on-premise can’t match, but only if parallelism is explicitly enabled per job type.
Tuning Parameters
# ION Grid Node - verify paths in your CloudSuite tenant config
grid.node.maxWorkerThreads = 20 # default often 8; increase for parallel batch
grid.node.taskQueueDepth = 500
# Batch chunk sizing (LPA / Landmark process agent config)
batch.commit.interval = 1000 # records per commit; tune between 500–2000
batch.fetch.size = 500 # cursor fetch size
# JVM heap per Grid node (verify with Infor Cloud Ops for your tier)
-Xms4g -Xmx8g
CloudSuite multi-tenant tiers may cap node resources — engage your Infor CSM to confirm whether your contract tier supports burst scaling for nightly batch windows.
Monitoring / Verification
Post-tuning, validate via ION Grid Management Console > Activity Monitor: target job-step elapsed times individually against your on-premise baseline. For 50K asset records, cloud environments with parallel node scaling enabled typically match or beat on-premise wall-clock time (verify in your version and tenant tier), but the gains are only realized if chunking and thread concurrency are explicitly configured — defaults favor stability over throughput.
This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Great question. In my experience, batch processing in CloudSuite can actually be faster than on-premise if configured correctly. The key is leveraging cloud scaling-you can allocate more compute resources during batch windows and scale down during business hours. However, network latency does matter if you’re integrating with on-premise systems during the batch run.
We migrated to ICS 2022 cloud last year with similar asset volumes. Our batch jobs initially ran slower-about 4 hours versus 2.5 hours on-premise. The issue was default resource allocation. Once we worked with Infor to optimize our batch job configuration and increase memory allocation, we got it down to under 2 hours. The cloud infrastructure is actually more powerful, but you need to tune it specifically for your workload patterns.
Carlos, that’s helpful. What specific optimizations did you implement? Were they configuration changes you could make yourself, or did they require Infor support involvement?
Most were self-service through the CloudSuite admin console-adjusting thread pool sizes, increasing JVM heap memory for batch processes, and enabling parallel processing for depreciation calculations. But for the really significant performance boost, we needed Infor to adjust our instance’s compute tier during our maintenance window. They can allocate more CPU cores temporarily for your batch window without changing your monthly cost much.
Don’t overlook database optimization. Cloud databases can have different I/O characteristics than on-premise. We saw 30% improvement just by reorganizing indexes and updating statistics before major batch runs. Also, if you’re reading from or writing to external systems during batch processing, that network hop adds latency that wasn’t there when everything was on-premise in the same datacenter.
Having managed both on-premise and cloud CloudSuite deployments for asset management, I can provide comprehensive insights on the performance differences and optimization strategies:
Network Latency Impact:
Network latency is real but often overstated. For batch processing, the main latency concern is if you’re pulling data from or pushing to external systems. Within CloudSuite itself, network latency is negligible-Infor’s cloud infrastructure uses high-speed internal networking. However, if your batch jobs integrate with on-premise databases, file servers, or APIs, expect 20-40ms additional latency per transaction versus 1-2ms on-premise. For 50,000 records, this can add 15-30 minutes if you’re doing real-time lookups.
Mitigation: Batch your external data calls. Instead of looking up reference data for each asset, load it once at the start of the job into memory. Use CloudSuite’s caching features for frequently accessed data.
Batch Job Optimization Strategies:
Parallel Processing: Cloud infrastructure excels here. Enable multi-threading for depreciation calculations. ICS 2022 supports up to 16 parallel threads for asset batch jobs. On-premise, you’re limited by your server’s CPU cores. In cloud, you can scale up temporarily.
Resource Scheduling: Configure your instance to use higher compute tiers during batch windows (typically 11 PM - 5 AM). Infor allows scheduled scaling where you automatically get 2x CPU and memory during these hours. This is a game-changer for performance.
Database Optimization: Cloud databases (especially if you’re using Infor’s managed database service) benefit from automated optimization, but you still need to maintain indexes. For asset processing, ensure indexes on asset_id, location_id, and status fields are optimized monthly.
Cloud Scaling Benefits:
This is where cloud truly shines. With on-premise, you size hardware for peak load, meaning it’s underutilized 90% of the time. In cloud:
Scale compute resources up during batch windows (automatic with proper configuration)
Use burst performance for unexpected workload spikes
Leverage cloud provider’s infrastructure redundancy for reliability
For your 50,000 asset scenario, I’d expect 1.5-2 hours in cloud with proper optimization versus your current 2-3 hours on-premise. The improvement comes from better resource utilization, not necessarily faster hardware.
Specific Recommendations for ICS 2022 Asset Management:
Enable ‘Batch Processing Optimization Mode’ in Asset Management configuration
Set batch job thread pool to 12-16 threads (test to find optimal for your data)
Configure database connection pooling to 100 connections for batch jobs
Use scheduled scaling to double resources during batch window
Implement data pre-loading for reference tables to minimize lookups
Monitor using CloudSuite’s built-in performance analytics to identify bottlenecks
The key insight: cloud performance isn’t automatically better or worse-it’s different. You need to rethink optimization strategies for cloud architecture. The flexibility and scalability are superior, but require active management to realize the benefits.