Infor Technology Blog

« | Main | »

Migrating Infor Lawson System Foundation from UNIX to Windows: Quickly and Reliably Reduce TCO

April 7, 2014

By Amruta Patel and Mark Hewitt

Infor Consulting Services (ICS) is excited to announce a new toolset available exclusively from Infor Consulitng Services: UNIX to Microsoft Windows migration tools. Customers interested in moving from UNIX platforms to the Microsoft Windows server platform can now change platforms quicker and easier by engaging with Infor Consulting Services and using the new UNIX to Microsoft Windows migration tools rather than the current manually intensive process.

Infor Lawson System Foundation (LSF) users have been requesting migration from traditional UNIX server environments to Microsoft Windows for some time now and used the Infor Lawson Global User Group (LGUG) Development Sub-committee to gain commitment to an effort to build tooling that would streamline the process and provide consistency from customer to customer.

Why Migrate to Windows?

Typical UNIX hosted LSF sites are large datacentres.  UNIX computing hardware, expertise and license costs are typically high.  Modern Windows systems deliver significantly more performance for the same investment cost, skills are better certified and less expensive to employ.  Add to that the cost and scalability incentives that cloud hosting offers, which is predominately Windows based, and the case for migration from traditional UNIX servers to Windows is very clear.

What Infor Offers

Infor has a fully scripted, reliable process that runs very rapidly to perform not only a UNIX to Windows migration of production LSF systems, but also permits upgrading to Infor Lawson 10 at the same time.  The process captures, transforms and reloads data relevant to the Technology and Security of the production LSF system.  It utilises an existing process for the separate migration of application data and the product line.

For security and audit purposes, a mapping of UNIX identities to Windows Domain\Username identities and LSF NTIDs using Resource Identities (RDIDs) is constructed and retained as part of the migration.  This mapping file is also especially convenient for creating new identities (across multiple domains as required) on the Windows system with the least fuss.

To allow for iterative migrations and to minimise access required to the source system, the tooling collects data using facilities always present on the UNIX systems and creates a migration package that is transferred to the target system.  Here, all the heavy lifting is done to transform the data suitable for reloading.  User identity information, file system conventions and service endpoints are all transformed both in the file system and in key database tables where they pertain to functional or security aspects of the system.

Data load is sensitive to the sequence in which it is performed and the tooling ensures that prerequisite steps are completed at each stage thereby maintaining data integrity.  Data load can also be spread across multiple concurrent processes to reduce load times.

Logging is provided on both source and target systems allowing the consultant to understand what has been done and if necessary, diagnose any issues that arise.

Migration between LSF environments of dissimilar versions is supported to the extent that a LSF or later UNIX system can be upgraded within the process to a LSF 10.0.2 (or later) Windows system, further reducing downtime and bringing users to a supported LSF 10 version.

The tooling comes as a single package that is installed to both the UNIX and Windows systems.  A small configuration file of around 10 key/value pairs describes how the migration will proceed.  Infor has also provided detailed documentation and a Microsoft PowerPoint presentation for educational purposes.  Currently, the UNIX to Windows migration tooling is only available via an Infor Consulting Services (ICS) engagement.

The Process


  • The tools are installed on each system.
  • The configuration file is updated to describe this particular migration – it can be the same on each system.
  • Verification and clean-up steps are executed as described in the documentation.

Data Capture

  • The tooling allows a dry-run to ensure that there’s enough space to construct the migration package.
  • Data capture scripts on the UNIX system grab and package up:
    • Security data
      • Security classes
      • Profiles
      • LAUA data (if required)
      • LSF LDAP data for user identities, security roles and services
      • SSOConfig service definitions
      • OS Users
  • Environment data
    • Tokens
    • Menus
    • Job definitions
    • Key Gen tables
    • Key LOGAN tables
    • Key Application tables where data content requires translation
    • Security configuration
    • Printfiles
    • IOS Portal persistdata
    • Work directories
    • Ownership and permission information

Simple Migration

In the simple case, the source and target systems are running the same LSF version.  In this case, the Windows system is created by:

  • Installing the target LSF environment in the usual way
  • Copying the product line and application data following that documented process
  • Transferring the migration package to the source system
  • Reviewing the configuration file to ensure it is correct and updating if necessary
  • Creating the OS users as required from the mapping data we provide
  • Running the load tools that:
    • Use a generic translation tool to transform file system and database data to:
      • Translate user identities to NTIDs in place
      • Translate file system naming conventions in place
      • Translate service endpoint definitions in place
    • Loads the data in parallel threads

Migrate and Upgrade

This is essentially the same as the simple migration process with the exception that we have two target product lines in the same (10.0.2.x or later) LSF environment.  The migration takes place to a copy of the source product line (which has a temporary name) and is then upgraded to the required release version:


Post Migration

There are a number of small post-migration tasks required where judgement is required or where there are no discernable mappings between the systems.

  • Adjustment to user defined tokens or customized scripts
  • Printer setup
  • Persist data setup



Leave a Reply

Your email address will not be published.