FactoryLink to Ignition Migration: Practical Guide 2026

What if the safest route from FactoryLink to Ignition is not a direct conversion, but a controlled redesign? A Factorylink to Ignition migration must preserve the behaviours operators rely on, not simply reproduce screens in a new platform. With FactoryLink now obsolete, the challenge is to replace it without overlooking alarms, sequences, interfaces or established workflows.

It is reasonable to be concerned that a like-for-like rebuild could miss something important, or that integration and cutover requirements will only become clear once work is under way. This guide sets out a practical method for discovering the existing system, mapping its functions and dependencies, and choosing a migration strategy that makes risks and validation visible before changes reach operations. It also explains how parallel running and structured testing can help manage the transition, depending on the site’s needs. From interface assessment to commissioning, the focus is on preserving essential control behaviour while planning a supportable Ignition system. For complex environments, AAC brings SCADA integration and mission-critical control-systems expertise to lifecycle engineering, helping align requirements, design and integration with operational continuity.

Why consider a FactoryLink to Ignition migration?

A migration is not simply the installation of new software. It is the planned replacement or redesign of selected control-system functions, with the operational behaviour they support deliberately maintained, changed or retired. Put simply: “Migration changes the control platform while preserving the functions and operating outcomes the site requires.” This distinction matters. Reproducing every legacy screen may carry forward old constraints, while a superficial rebuild can overlook essential alarms, sequences or interfaces.

FactoryLink’s end-of-life status is one potential reason to assess the system: Siemens ended development in 2007 and support for version 8 in October 2012. That history alone does not establish the business case or mean every installation faces identical risks. Consider a Factorylink to Ignition migration in the context of the site’s actual supportability, operational needs and future plans. Ignition is a different platform. An overview of the Ignition SCADA platform can help orient stakeholders, but project requirements and compatibility must be established against the installed system.

What should trigger a FactoryLink migration assessment?

Begin by recording why the system is being reviewed, separating verified constraints from assumptions about an older platform. Assess whether the site can maintain the current runtime and supporting infrastructure, whether key knowledge is concentrated among a small number of people, and whether planned changes to servers, networks or connected systems create an opportunity to modernise. Document specific operational pain points, such as difficult-to-maintain workflows or integration needs, rather than treating age alone as proof that a function no longer works.

Involve operations, OT engineering, IT, maintenance and project leadership. Operations can describe how the system supports day-to-day tasks; OT engineers and maintenance teams can explain control behaviour and dependencies; IT can contribute infrastructure and cybersecurity requirements; and project leaders can align scope, sequencing and acceptance decisions. Their combined view helps distinguish a technical obsolescence issue from an operational limitation or a deliberate modernisation objective. The drivers and acceptable level of change will be site-specific.

What does a successful migration need to preserve?

Start by identifying what the system must continue to do, not just what it displays. Prioritise required control behaviour, operator tasks, alarms and external interfaces. Include how users recognise abnormal conditions and what actions they are expected to take. Documenting these details gives engineering and operations teams a shared basis for defining requirements and assessing whether the replacement behaves as intended.

Then classify each function as mandatory, suitable for improvement or no longer required, involving the relevant operational owner in each decision. A screen may be redesigned for clarity while its associated response remains essential. An old workflow may be simplified, but only after its purpose and dependencies are understood. This prevents a screen-by-screen copy from becoming the migration specification. In environments where SCADA connects operational areas and systems, the wider context matters too. AAC’s airport SCADA integration guide explores how interfaces and operational requirements fit into broader modernisation planning.

How to map FactoryLink functions to Ignition requirements

A reliable mapping starts with evidence of what the existing application does, including the less visible behaviours operators and maintainers depend on. Inventory screens, tags, alarms, sequences, reports, users and external interfaces. Treat each item as a requirement to investigate, not an object to copy. Requirements mapping must precede platform configuration because the team needs to define the required behaviour before deciding how to implement it.

For each function, record its purpose, operational owner, dependencies, criticality and evidence that will demonstrate acceptance. A tag, for example, is not fully described by its name and value. Establish what uses it, whether it contributes to an alarm or sequence, and what a user or connected system expects to happen when it changes. In a Factorylink to Ignition migration, this function-by-function approach avoids assuming that source objects have direct equivalents in the destination design.

• Screens and users: note the task supported, user group, navigation path and any role-based access needs.
• Tags and alarms: record sources, meaning, alarm conditions, priorities and expected operator response.
• Sequences and scripts: capture initiating conditions, steps, interlocks, exceptions and recovery behaviour.
• Reports and interfaces: identify consumers, data exchanged, timing expectations and dependencies.
• Acceptance evidence: define the test, record or observed result that will show each requirement has been met.

Which application and control dependencies should be documented?

Trace each function through its connected environment, including PLCs, field devices, databases, networks and third-party interfaces. Document tag structures, scripts, alarm responses and sequence behaviour where present. Note which components provide data and which rely on it. Check protocol support against the specific FactoryLink, Ignition and device versions, using project documentation rather than assumptions based on product names. This creates a practical dependency map for design and test planning.

Include security-related dependencies, such as accounts, access paths and connections between operational components, then assess them against the site’s requirements. The NIST Guide to Industrial Control Systems Security provides broader ICS security guidance that can inform this review. Determine which recommendations apply to the specific project and environment.

How can teams capture undocumented operational knowledge?

Walk through representative tasks with operators, maintainers and controls engineers. Record what happens during normal operation, abnormal conditions and recovery. Ask participants to explain their decisions and expected responses, not just which buttons they press. Compare observations with available specifications and note unresolved differences for review. AAC’s control systems design consultancy guide provides lifecycle context for connecting requirements with design and engineering decisions.

Use the resulting map as a controlled working document. Assign owners to open questions, track decisions and link each requirement to its planned acceptance evidence. This gives operations, engineering and project leadership a shared basis for shaping the Ignition design before configuration begins.

Which FactoryLink-to-Ignition migration approach fits the system?

There is no universal migration pattern. The right approach depends on how tightly functions are connected, which system owns each data point and what operating constraints govern change. Ignition should not automatically be treated as a screen-for-screen replacement for FactoryLink. Rebuilding displays without reconsidering underlying functions can preserve unnecessary complexity, while replacing them without accounting for control behaviour can introduce gaps.

Compare the options against prerequisites, benefits, limitations and project conditions. Staging and parallel operation can be combined, but they are not the same: staging describes how work is divided, while parallel operation describes a period when both systems are running.

• Staged migration. Prerequisites: functions can be separated into well-defined groups with understood dependencies. Strength: teams can deliver and assess portions of the redesign in sequence. Limitation: boundaries must not interrupt shared functions or leave ownership unclear. Suitable where functions can be isolated and each stage has defined acceptance criteria.
• Parallel operation. Prerequisites: both environments can run together safely, with interfaces, data ownership and operating rules documented. Strength: it allows the new system’s behaviour to be assessed alongside the existing one before transition. Limitation: duplicated or conflicting commands and data must be prevented, and coexistence adds coordination and support demands. Suitable only where the architecture and site conditions support a controlled overlap.
• Planned cutover. Prerequisites: dependencies are understood, readiness criteria are met and an authorised change window is feasible. Strength: it avoids maintaining two active environments for an extended period. Limitation: a tightly coupled system can make the change harder to divide and recover. Consider only after a site-specific risk assessment, with rollback conditions and decision authority agreed in advance.

When is a staged or parallel transition appropriate?

Assess whether functions can be separated without weakening control or supervisory responsibilities. For each proposed stage, define which system owns readings and commands, the direction of each interface, and what operators should do during coexistence. Propose parallel running only after engineering review confirms that both environments can operate safely together. It is not automatically lower risk just because the legacy system remains available.

When might a single cutover be considered?

A single cutover may warrant assessment where functions are tightly coupled and splitting them would create complex dependencies, provided the site can plan a controlled change window. Before approval, document entry conditions, checks, rollback triggers and who has authority to proceed, pause or reverse the change. Base the decision on evidence about system behaviour and operating constraints, not a general preference for one migration method.

Legacy components may sometimes remain in the target architecture, but only where their interfaces and support conditions make that arrangement viable. The Factorylink to Ignition migration strategy should follow the system’s dependencies and operational requirements, rather than a fixed template.

How to plan testing, cutover and operational handover

Testing and commissioning should demonstrate that the agreed requirements work as intended in the operating context, not merely that the new application starts. For a Factorylink to Ignition migration, define acceptance criteria before testing begins, then use the results to guide the cutover decision. In a demanding environment, including an airport, clear ownership, communication and decision points help teams manage change around operational constraints.

What should FactoryLink-to-Ignition testing cover?

Build the test plan from the approved requirements map. Cover individual functions and how they work together, including interfaces and operator responses. Agree representative normal, exception and recovery scenarios with operational stakeholders. For example, a test might verify that a required alarm appears, prompts the intended operator response and clears according to the defined conditions. Base the scenario on the actual requirement, rather than assuming every alarm behaves alike.

Use an ordered sequence to find and resolve issues before the system is relied upon live:

1. Approve requirements. Confirm scope, function ownership, dependencies and acceptance criteria with operations, OT engineering, IT and project leadership.
2. Verify the design and test basis. Confirm interfaces, data sources, alarm behaviour, access arrangements and test conditions against project documentation.
3. Test mapped functions. Check required screens, sequences, reports, alarms and operator workflows, including relevant abnormal and recovery cases.
4. Exercise interfaces and data. Verify expected exchanges with connected systems and assess data quality against agreed requirements.
5. Record and resolve findings. Log results, defects, corrective actions and retests, linking each outcome to its requirement.
6. Approve commissioning and acceptance. Review evidence with designated stakeholders and record the decision to proceed, defer or address outstanding items.

Acceptance should be evidence-based. A successful screen check alone may not demonstrate that a sequence, interface or operator response meets its requirement. Keep unresolved defects visible, assess their operational significance and assign an authorised decision-maker to determine whether they affect readiness.

What belongs in cutover and handover planning?

Cutover planning should set out the sequence of change, named responsibilities, communications, decision points and rollback criteria, shaped around site constraints. Define who can authorise proceeding or reversing the change, what evidence supports that decision, and what conditions require a pause. Plan communications so affected teams understand the timing, expected workflow changes and escalation route.

Handover is part of the engineering work, not an administrative afterthought. Prepare current system documentation, operating procedures and maintenance information, and arrange training so operators understand changed workflows before live operation. Make clear who owns outstanding actions and where approved test and commissioning records are held. This supports continuity beyond the project team’s involvement.

For more on how AAC connects requirements, integration and commissioning, read about AAC’s control-systems migration services.

How AAC supports mission-critical control-system migration

A complex migration needs more than platform configuration. It requires engineering decisions that connect operational requirements with system architecture, interfaces, commissioning evidence and the people responsible for running the system. AAC’s SCADA integration and mission-critical control-systems experience supports this joined-up approach, with control-systems design delivered across RIBA Stages 1 to 5. This provides a lifecycle framework for developing requirements and design through to integration and commissioning, tailored to the project’s scope.

For airport environments, system changes must be considered alongside operational continuity and connections between control systems. The aim is not to assume a particular FactoryLink installation or prescribe a standard design, but to make responsibilities, dependencies and evidence clear before decisions reach implementation. A Factorylink to Ignition migration can then be planned around the site’s actual functions and constraints, rather than treated as a generic software replacement.

What does lifecycle engineering bring to a migration?

Early requirements and architecture choices shape what can later be integrated and how the result will be commissioned. If responsibilities for data, interfaces or operator actions are unclear at the design stage, those uncertainties can surface as test gaps or late changes. Coordinating operations, controls, IT and project teams helps make these boundaries explicit and gives commissioning a traceable basis. Each requirement can be connected to a design decision and then to evidence that the intended behaviour has been tested.

Where an architecture discussion would benefit from a standards-based perspective, AAC’s IEC 61499 architecture guide offers relevant context. Consider its relevance against the project’s specific requirements rather than assuming it determines the migration design.

What information helps scope an initial discussion?

A concise overview can help establish the operational context and the questions that need further investigation. Useful starting information includes:

• System purpose and critical functions: what the control system supports and which behaviours are essential to operations.
• Connected equipment: known PLCs, field devices, databases, networks and third-party systems.
• Operating constraints: access, outage or sequencing considerations that shape how change can be planned.
• Existing records: diagrams, application documentation, interface records, alarm information and known dependencies.
• Project drivers: supportability concerns, infrastructure plans, operational limitations or modernisation objectives.

Complete documentation is not a prerequisite for a useful conversation. Available records, known gaps and input from the people who operate or maintain the system can help identify where discovery is needed before scope and delivery stages are defined. AAC can align this early assessment with its control-systems design and integration capability, while tailoring the approach to the migration.

For an overview of AAC’s control-systems design and integration capability, visit AAC’s website.

Turn migration planning into a controlled next step

Turn the assessment into a decision-ready project brief: define the operational outcomes, identify unresolved dependencies and agree what evidence will be needed before any change is approved. This gives stakeholders a sound basis for determining scope and sequencing, while keeping the focus on continuity rather than software replacement alone.

For a Factorylink to Ignition migration in a demanding operational environment, AAC brings specialist SCADA integration and mission-critical control-systems capability, with control-systems design across RIBA Stages 1 to 5. AAC is also a Schneider Electric EAE Master Partner and UAO member. This experience supports a considered engineering discussion without assuming that every site needs the same migration pathway.

Share your system’s purpose, critical functions, interfaces and operating constraints to begin a focused conversation about the engineering requirements. Discuss your control-systems migration requirements with AAC and take the next step towards a migration plan grounded in your operational priorities.

Frequently Asked Questions

Is there a direct FactoryLink-to-Ignition converter?

No. Siemens has not provided a customer-runnable FactoryLink-to-Ignition conversion tool, so treat the work as an engineering redesign rather than a one-click transfer. First identify which source behaviours and dependencies matter, then define how the required outcomes will be implemented and verified in Ignition. A display may be recreated differently if its operator task and alarm response are preserved. Scope depends on the installation and connected systems, so validate technical details against project records.

Can existing PLCs remain in place during a FactoryLink-to-Ignition migration?

Yes, existing PLCs may remain if the target architecture, communications and operating requirements support that choice. Keeping a controller does not mean every supervisory function will continue unchanged. For example, a PLC may still execute its control logic while the new SCADA application uses different data exchanges or alarm handling. Record which system reads or writes each value, check compatibility for the relevant versions, then verify representative functions before fixing the migration boundary.

What happens to historical data when moving from FactoryLink to Ignition?

Historical data needs its own retention and access plan. Do not assume it will transfer automatically with the live application. Identify which records users need, where those records are stored, how they will be retrieved and whether their format supports the intended use. For instance, operators may need to consult past events even if the new system begins collecting live data separately. Agree data acceptance requirements during discovery and test retrieval before relying on the new arrangement.

Can FactoryLink scripts and custom functions be reused in Ignition?

Do not assume FactoryLink scripts or custom functions can be copied unchanged into Ignition. Examine each function to determine its operational purpose, inputs, outputs, permissions and dependencies, then decide whether it remains necessary. A script that appears minor may handle an exception or recovery condition. The target design should meet an approved requirement, and testing should exercise both expected and abnormal behaviour, including what happens when a dependency is unavailable or a user lacks permission.

How long does a FactoryLink-to-Ignition migration take?

There is no dependable duration that applies across installations. The schedule depends on factors such as application complexity, available records, connected systems, control dependencies, required testing and the chosen transition method. A preliminary assessment can separate discovery, design, implementation and commissioning work, while identifying access or operational constraints that affect sequencing. Treat any timeline as specific to its defined scope and assumptions, not as a general benchmark for other FactoryLink projects.

How do you verify that an Ignition system meets operational requirements?

Set measurable acceptance criteria before configuration, then link each requirement to a test result or other observable evidence. As well as checking individual functions, test how connected systems respond to exchanged data and confirm that alarms lead to the intended operator action. Include realistic scenarios agreed with site stakeholders, such as an exception followed by recovery. Record defects, retests and approval decisions so the project team can see what has been demonstrated and what remains unresolved.

What documentation is useful before a FactoryLink migration assessment?

Useful records include architecture drawings, application and tag documentation, alarm lists, interface schedules, network diagrams and operating procedures. A list of connected equipment and known dependencies can also help frame the review. Documentation may not reflect current practice, so operators and maintainers can clarify how particular screens, alarms or sequences are actually used. Mark gaps clearly and investigate them; missing paperwork alone is not evidence that a function is obsolete or unused.