Infor VISUAL to CloudSuite Migration

If you are running Infor VISUAL today, you already know what a job traveler looks like, how resources get scheduled against capacity, and how a BOM rolls up into a job. This is not an explainer on what an ERP is. It walks through what actually happens, mechanically, when a VISUAL environment moves to CloudSuite Industrial: how the migration utility works, what data does and does not move automatically, where customizations and integrations need rework, and what decisions you need to make before anyone touches a production database. Infor provides a structured path for this through the Infor Leap program and a migration utility with mappings already predefined for VISUAL, and this article walks through both.

Why VISUAL Users Are Evaluating CloudSuite Right Now

The pressure behind this question is architectural before anything else. VISUAL runs as a client server application: a SQL Server database and application logic on the server side, with a Windows client connecting to it. CloudSuite Industrial runs in a browser, hosted on a multi tenant cloud. Infor frames this directly on its ERP migration page, stating that the shift to cloud ERP is no longer a question of if but a matter of when, and that companies of all sizes are moving from on premise ERP to CloudSuite, powered by what Infor calls its Industry Cloud Platform.

That shift is not cosmetic. Infor’s CloudSuite environment is positioned by Infor as combining generative AI, robotic process automation, process mining, machine learning, and agentic AI, hosted by AWS in a multi tenant cloud built for scalability and security. None of that layer exists in an on premise VISUAL deployment, because VISUAL was never architected as a multi tenant cloud product. So the real question is not whether CloudSuite has more features in a brochure sense. It is whether the operational model, browser based access, centralized patching, and a cloud native integration layer, fits where the business is going. That deserves a technical answer rather than a marketing one.

What the Migration Utility Actually Does

This is the part most VISUAL users want to understand, because it determines how much risk and effort the project carries.

Source Tables, Target Tables, and the Migration Database

The migration utility does not copy your VISUAL database directly into a CloudSuite database. Data moves into an intermediate CloudSuite migration database first, and only after it is validated does it get copied into a production CloudSuite database. Inside that migration database, Source Data Load tables hold the data pulled from VISUAL, structured according to the import_source_object and import_source_column tables, which store the table and column names from your source database. Target Data Load tables are built from the import_target_object and import_target_column tables, and only contain a subset of the columns in the actual CloudSuite tables, specifically the columns that are part of a defined mapping.

The column level relationships between source and target are governed by the import_mapping table, which stores, for every target table and sequence combination, exactly which source object and column maps to which target column. For a VISUAL migration specifically, this is not built from scratch. Infor states plainly that a sample set of mappings, transformations, and rules has already been predefined for the VISUAL migration, a meaningfully different starting position than migrating from a non Infor system, where that mapping work has to be built manually before any data moves.

Why Sequence Numbers Are Not Optional

Every mapping in the Import Steps form carries a sequence number, and that number is not a sorting convenience. Target tables have real dependencies on each other. Infor’s documentation uses Unit of Measure as the textbook example: Unit of Measure codes must be defined before Unit of Measure Conversion data can be loaded, because the conversion records reference codes that need to already exist. Run sequences out of order and the import either fails outright or, worse, succeeds while creating data integrity problems that surface later.

This is also why the predefined mappings and sequences for the VISUAL migration, configured and tested by Infor, should only be modified by a qualified consultant. You can add new mappings and sequences for a custom table or column outside what is predefined, but inserting a new sequence between two existing ones requires understanding every downstream dependency it touches. Some target tables appear in more than one sequence, because certain columns are prerequisites for other tables while other columns in the same table have to wait on data that has not arrived yet.

Preliminary Transfer vs Final Transfer, and Why Skipping the Preliminary Step Is a Mistake

The preliminary data transfer does not move a single record into your production bound target table. Its only job is to test whether the data in a given sequence can move from source to target without errors, comparing column length and data type between the two systems. If everything passes cleanly, you move straight to the final transfer. If it does not, the utility attempts to automatically generate a correction rule and flags it for review in the Import Table Column Rule Definition form.

Infor defines several types of these system generated rules, and understanding them is the difference between fixing a migration issue in minutes versus hours. A renew value rule fires when an existing value in your VISUAL table is not valid for the corresponding CloudSuite column’s data type, requiring you to supply a replacement for each problematic value. A default value rule fires when CloudSuite requires data in a column that VISUAL does not require, asking you to supply a default whenever the source does not provide one. A third type, update references to modified data, handles cases where a value such as an account number exists in multiple tables, so changing it in one place updates every referencing table. A fourth, more specialized type covers account number and unit code setup. You rerun the preliminary transfer, review whatever rules were generated, supply values, and repeat until the sequence produces zero errors before touching the final transfer. Skipping straight to the final transfer without working through preliminary errors is how migrations end up with silently corrupted reference data discovered weeks later. This kind of disciplined, sequence by sequence validation reflects a structured approach to ERP data migration generally, not just something specific to the VISUAL to CloudSuite path.

What Does Not Migrate Automatically, and Why That Matters

This is where a lot of VISUAL users get surprised, because the assumption going in is often that the migration utility is a full historical replica tool. It is not. Infor says so directly: the migration focuses on the master data and open transactions of the external application, with the explicit goal of letting you resume business activity with minimal disruption, not recreating your entire transactional history.

Labor ticket data is a clear example. Posted data, meaning transactions already finalized and recorded in VISUAL, is generally outside the scope of what the standard migration brings over automatically. If a business genuinely needs that posted history inside CloudSuite, it has to be handled as a deliberate manual load into the appropriate load table.

Released jobs are the other significant case. If a job has already been released in VISUAL with material movement against it, that movement does not transplant itself as a static record in CloudSuite. Infor’s documentation states that material issue transactions for imported released jobs must be re created in CloudSuite so the correct material transactions, journal entries, and supporting data such as WIP are generated correctly. The Import Job Material Transactions form is where you review transaction date, job and suffix, operation and sequence number, item and quantity, lot or serial information, warehouse and location, and the full cost breakdown before the final transfer runs. The same logic applies to inventory: quantity on hand values are not just dropped in as numbers. They come in through miscellaneous issue or receipt transactions using reason codes you define in the Import Parameters form, so the corresponding material transactions, journal entries, costing, lot, and serial data get created correctly rather than existing as orphaned balances.

A VISUAL user planning this migration needs to budget real time and real people for reviewing inventory balances and job material transactions before the final transfer runs, not assume that everything simply moves over because it lived in a table somewhere in VISUAL.

Customizations: The Part Infor’s Sales Materials Undersell

CloudSuite Industrial’s multi tenant cloud architecture inherently limits the kind of customization possible compared to an on premise, client server VISUAL environment where you have direct access to the database and application layer. If your VISUAL environment has stayed close to standard functionality, the customization conversation in a migration project is short. If it has accumulated custom forms, custom stored procedures, or heavily modified business logic over years of operation, that conversation becomes one of the most important parts of the project, because each piece of customization and extension work within VISUAL environments needs to be individually assessed against what is achievable in a multi tenant CloudSuite deployment.

This is not a reason to avoid custom logic during the migration itself. Infor’s migration utility documentation acknowledges that stored procedures are predefined to handle standard table mapping, but also states that you can work with Infor Consulting Services to create a custom stored procedure to move data the utility cannot handle with the existing procedures. The same applies if you need a manual import rule beyond the four system defined types: you create the rule definition, then a custom stored procedure executed inside the ApplyImportRuleSp procedure is needed to apply it, and Infor again points to Consulting Services or a qualified partner. The honest framing is this: migrating the data itself is well documented and largely mechanical. Migrating your customization footprint is not, and deserves its own assessment phase before you commit to a timeline.

Integration Behavior Changes: ION Becomes the Backbone

If your VISUAL environment currently talks to other systems, whether a CRM, an EDI provider, a CPQ tool, or your financial reporting stack, it is most likely doing so through direct database connections, point to point interfaces, or third party middleware. That model changes under CloudSuite Industrial, which uses Infor ION integration architecture, Infor’s Intelligent Open Network, as its integration layer. ION does not move raw rows from one database to another. It converts data into standardized Business Object Documents that move between applications through defined connection points and document flows rather than a direct pipe between two databases.

The practical implication is that you cannot assume an existing VISUAL integration carries over unchanged just because the same two systems still need to talk after the migration. Each integration point has to be re mapped through ION. In ION Desk, you model document flows between applications, which can represent a full business process or a narrower technical exchange, including filtering and content based routing where data from a third party application is translated into the standard Business Object Document format an Infor application expects. Once a flow is activated, the ION Service enforces it in production and provides monitoring and troubleshooting for what is moving and what is failing.

If your integration map is simple, this is contained work. If several systems feed VISUAL through different mechanisms, mapping out how ION connection points and document flows are configured for each becomes its own workstream that should be scoped alongside the data migration, not treated as an afterthought once data is already in CloudSuite.

The Two Realistic Migration Paths: Infor Leap vs a Standard Project

VISUAL users essentially have two routes into CloudSuite, with different tradeoffs around cost certainty and timeline control.

The first is Infor Leap, Infor’s own fixed fee, fixed timeline program built for existing on premise and single tenant customers. Infor describes Leap as eliminating the traditional risks of cloud migration through a fully scoped solution with a guaranteed price and transparent go live date before you commit, backed by an exclusive two year satisfaction clause. The program starts with a complimentary Cloud Readiness Workshop led by Infor’s industry experts, meant to scope the realistic shape of your migration before any contract is signed. Leap customers pay no additional CloudSuite software fee in the first year, with an option to add Infor Velocity Suite and get the first year free as well. Infor has also referenced an independent Forrester Total Economic Impact study on the return on investment of Infor CloudSuite, hosted on its own site, though specific figures from that study were not part of the source material used here and should be verified directly against the report if that level of detail matters to your decision.

The second route is a standard scoped migration project, typically run through a qualified Infor partner, where cost and timeline are negotiated based on your data volume, sequence complexity, and customization footprint rather than fixed in advance. This gives you more flexibility to structure the project around your internal team’s availability, but without Leap’s upfront price and date guarantees. Whichever route you choose, the work benefits from a technical framework for a structured Infor implementation that governs how project phases, testing, and go live readiness are managed, separate from the data migration mechanics themselves.

A Practical Pre Migration Checklist for VISUAL Users

Before any sequence runs in the migration utility, there is real groundwork to complete, and Infor’s planning documentation is specific about it. Start by completing and posting every open transaction in VISUAL: unposted invoices, vouchers, journals, and job transactions, along with printing and posting outstanding accounts payable and payroll checks. Infor’s guidance states that after these steps are performed, no new transactions should be created in the source application, with any new activity from that point forward belonging in CloudSuite instead. Treat this as a hard cutover line, because the migration utility assumes VISUAL has stopped accepting new activity once the transfer begins.

Alongside that, document your actual customization footprint, meaning every custom form, modified business process, and custom stored procedure running against your VISUAL database, since this determines how much Infor Consulting Services involvement the project will need. Build a complete inventory of every external system integrated with VISUAL and how each connects today, because each connection needs a corresponding ION mapping decision before go live, not after.

You also need the planning spreadsheet Infor’s documentation describes, listing every CloudSuite form where data must exist, the underlying CloudSuite table for that form where one exists, and the matching VISUAL table and sequence position based on data dependencies. Infor notes this spreadsheet may already exist for a VISUAL specific migration and is worth requesting directly from your Infor consultant. Finally, write the verification plan before the first sequence runs, not after the data has already landed, and share it with the other departments that will use the migrated data so each one can confirm what they see in CloudSuite matches what they expect based on VISUAL. Only after that plan exists and the data has been verified against it should you take the backup that marks the end of the migration phase.

What Should You Do Next

The mechanical side of this migration is, frankly, well documented. Infor has published the sequence logic, the rule types, the inventory and job material review steps, and a working example built specifically around VISUAL. Where a VISUAL user genuinely needs judgment, not just a checklist, is the customization assessment, the integration remapping through ION, and how much historical data needs to move versus what can be archived and left behind. The migration utility cannot make those decisions for you. Having actually run the sequences, reviewed the rule corrections, and rebuilt the integration points on both the VISUAL and CloudSuite sides is what tends to separate a migration that goes live on schedule from one that stalls in the middle of sequence reviews.

Frequently Asked Questions

Can we migrate only some of our VISUAL data to CloudSuite, or does it have to be all or nothing.

It does not have to be all or nothing, and in fact Infor’s own migration utility is built around partial scope by design. The tool focuses on master data and the open transactions needed to resume business operations, not a full historical replica, so deciding how much history to bring over is a planning decision your business makes rather than a technical limitation imposed by the migration utility itself.

Will our custom VISUAL reports and stored procedures carry over to CloudSuite.

Not automatically. The migration utility supports custom stored procedures for the migration process itself, meaning moving data the standard procedures cannot handle, but that support requires working with Infor Consulting Services to build those procedures. Report level and form level customizations are a separate question entirely and need to be assessed against CloudSuite’s customization model, since the multi tenant cloud architecture constrains what kinds of customizations are achievable compared to an on premise VISUAL environment.

How long does a typical VISUAL to CloudSuite migration take.

Infor does not publish a universal timeline because it genuinely depends on your data volume, the number of sequences involved, and how much customization needs to be assessed or rebuilt. The one place Infor does offer timeline certainty is through the Leap program, which is built specifically to provide a fixed, transparent go live date as part of its fixed fee structure, making it the closest thing to a guaranteed timeline that Infor itself offers.

What happens to in progress jobs and WIP during the migration.

Released jobs do not just transplant as static records. Infor’s documentation states plainly that material issue transactions for released jobs need to be re created in CloudSuite so that the correct material transactions, journal entries, and WIP data are generated on the CloudSuite side, reviewed through the Import Job Material Transactions form before the final transfer runs.

Do we need to involve Infor Consulting Services, or can our own team run the migration utility.

It depends on how much you are modifying. Infor is explicit that the predefined VISUAL mappings and sequences should only be modified by a qualified consultant, since changing them without understanding the downstream dependencies risks data integrity problems. Routine execution of the preliminary and final transfers for the standard, already mapped sequences can reasonably be handled by an internal team that knows the relevant forms, so the realistic answer for most projects is a hybrid: internal team for execution, consultant involvement for anything touching sequence logic or custom stored procedures.

Does CloudSuite Industrial replace VISUAL’s scheduler functionality.

This is worth validating rather than assuming. VISUAL’s patented Engineering Master and Production Scheduler, including its finite and Drum Buffer Rope scheduling models, is one of the defining features Infor markets specifically for VISUAL. Whether CloudSuite Industrial’s own scheduling and advanced planning capabilities match that functionality for your specific operation is a legitimate comparison to validate directly against your current scheduling requirements rather than assume feature parity by default.