STEP 7 Classic to TIA Portal: Migration and Data Tests

STEP 7 Classic to TIA Portal migration involves two decisions: moving a project into a different engineering environment and, if required, moving its program to a different controller. Keeping an S7-300 or S7-400 target is not the same task as replacing it with an S7-1500. The required tools, supported objects and validation work depend on the actual route.

For TIA Portal V20, there is an important change from many older tutorials: Siemens no longer supports integrated migration of STEP 7 .s7p projects directly into TIA Portal. Its documented route uses the migration tool to produce an .am20 file first. This guide uses the V20 documentation checked on 12 September 2026 and explains how to organise a migration exercise without confusing conversion success with equivalent behaviour.

We operate PLC Simulation Software and may benefit from its use. Product links support general data-handling and testing practice. The browser product is not a STEP 7 migration tool and is not presented as a way to open, convert or execute the native project discussed here.

Separate project migration from controller replacement

Start by writing down the source engineering version, the existing CPU and the intended target. Then state whether the project must remain associated with the original controller family or support replacement hardware. “Upgrade to TIA” is too vague to determine the work or accept a quotation from a training or engineering provider.

Siemens' V20 STEP 7 migration documentation explains the .am20 route and the distinction between migrating software alone and including supported hardware configuration. Software-only migration can create unspecified devices; it does not establish a finished hardware and network configuration.

For replacement with an S7-1500, Siemens documents a separate PLC program migration procedure. That procedure converts the program into a new device and requires manual configuration of the replacement hardware. It also calls for processing the migration log and compiling the migrated project. Do not treat a program conversion as automatic transfer of every rack, network and field-device setting.

This distinction helps South African learners evaluate course descriptions. A short demonstration that imports an engineering project is useful, but it is not equivalent to a practical assessment covering CPU replacement, communications, HMI interfaces and restart behaviour. Ask which part you will perform and which evidence you will submit.

02

Preserve a reference before changing anything

Work on a copy of the source project. Keep the original archive, a note of the software needed to open it and the documents that explain the application. If the exercise uses a supplied training archive, record its revision and the instructor's initial conditions so results can be compared fairly.

A source-project archive and an upload from a controller are not automatically interchangeable evidence. Establish what each available artifact contains and what is missing before choosing a recovery plan. Symbols, comments, source files, external configuration and current operating values can belong to different parts of the engineering and running system.

Build an inventory that goes beyond block counts. Include CPU and module identifiers, network devices, communication partners, external tag consumers, libraries, protected components and optional software. Record each item's intended treatment: migrate, replace, rebuild, retire or investigate. An unresolved item should remain visible rather than disappearing because the first conversion completed.

Keep current operating values separate from program structure. A recipe, calibration value or accumulated total may require a defined capture and restoration procedure. Copying an entire data block without understanding its fields can transfer stale state or omit a required value. For a classroom exercise, use explicit synthetic values so learners can see the difference between a default and a preserved value.

Check the toolchain and the source project's consistency

Siemens' migration-tool system requirements list supported source products starting with STEP 7 V5.4 SP5 and require the source products and relevant optional packages. This is more precise than claiming that every project must first be saved in one particular V5.5 service pack. Check the actual route and installed products before deciding on an intermediate environment.

The STEP 7 migration prerequisites cover consistent hardware and software, required components and compilable source programs. Review protection and library constraints through the authorised project owner. A missing password or unavailable vendor source is an engineering dependency to resolve, not a reason to claim the conversion is complete.

Before running the tool, produce a clean reference that the source environment can process. Distinguish an existing source defect from a new migration defect. If the original exercise already misclassifies an input, faithfully preserving that behaviour may demonstrate equivalence while still failing the intended requirement. Decide whether the task is preservation, correction or both.

For protected supplier blocks, request a supported target version or an approved migration route. Do not assume that a block which appears in the project tree can be opened, modified and recompiled in every environment. Keep the supplier response with the migration evidence so the limitation is visible to the next person reviewing the project.

Create the migration file and inspect the result

Siemens' migration-file instructions describe selecting the source, choosing whether hardware and network data are included, and creating an intermediate file for the target system. Use the appropriate licensed source environment and the documented tool for the selected version.

Record the selected scope beside the resulting file. A software-only artifact can be appropriate for a planned rebuild, but it should not be mistaken for a full migration. Conversely, including configuration data does not guarantee that all source components have supported equivalents on the target. Inspect the actual result rather than inferring completeness from the checkbox alone.

Keep the migration log as part of the exercise. Siemens provides a migration-log view for inspecting the result. Treat each relevant message as an item that needs an interpretation, an action where required and a verification result.

Do not invent a typical conversion percentage or use a clean-looking progress bar as acceptance evidence. A small unresolved communication block can matter more than hundreds of straightforward converted networks. The useful measure is whether every required behaviour and interface has a supported implementation and an appropriate test.

03

Group the remaining work by observable behaviour

Create separate review groups for logic, data representation, execution timing, communications, operator interfaces and lifecycle events. This is more useful than sorting only by block number because a single visible function can depend on several blocks and an external consumer.

For logic, compare the required conditions and state transitions. For data, compare types, units, ranges and layout assumptions. For timing, identify task events and call frequency. For communications, identify the requested data, partner, status handling and recovery behaviour. For an HMI, check what a user sees and what a write actually changes.

Avoid a blanket rule that every legacy instruction is replaced by a similarly named modern instruction. Review the migration message and the documented semantics for that operation. A name that sounds equivalent does not establish matching parameters, status codes, asynchronous behaviour or supported targets.

The TIA Portal FB and instance guide helps inspect data ownership. The communication troubleshooting guide helps follow an interface through its stages. Use these as focused follow-up topics rather than trying to resolve every dependency by editing the first block that reports an error.

Worked exercise: preserve a recipe's meaning across representations

The following example is fictional. It is designed for migration assessment and is not a Siemens memory-layout description, native conversion function or live recipe-restoration procedure. The source record contains SpeedTenths, CountWord and Enabled. The target record contains Speed, Quantity and Enabled.

The source speed is an integer from zero through 800, representing tenths of a unit. The target speed is the corresponding value from zero through 80, so 355 means 35.5. The source count is an unsigned 16-bit storage value containing four packed decimal digits; each four-bit digit must be zero through nine. The resulting quantity must be from one through 500 inclusive.

The source enabled field must be Boolean. Validate the complete record before producing an accepted target record. If any field is invalid, report rejection and do not publish a partly updated target. This all-or-nothing rule is part of the classroom converter; it is not a claim that a native data-block write or HMI transfer is automatically atomic.

Source field	Example	Intended target meaning
SpeedTenths	355	Speed 35.5
CountWord	Hexadecimal 0125	Quantity 125
Enabled	true	Enabled true

Hexadecimal 0125 is a storage pattern whose nibbles are 0, 1, 2 and 5. Interpreting the whole word as an ordinary binary integer gives 293, which is not the required decimal quantity. The data conversion guide explains why representation and meaning must be established before values are copied.

04

Calculate the expected results before writing a converter

For a four-digit packed decimal word, extract thousands, hundreds, tens and units. Reject any digit above nine. The decoded quantity is one thousand times the first digit, plus one hundred times the second, plus ten times the third, plus the fourth. Then apply the separate application limit of one through 500.

The storage pattern 0500 contains valid decimal digits and decodes to 500, which is accepted. Pattern 0501 also contains valid digits but decodes to 501, which is outside the recipe limit. Pattern 001A is invalid packed decimal because its final nibble is ten. These failures have different causes even though neither should produce an accepted recipe.

A zero word is valid packed decimal representation but produces a quantity of zero, which this application rejects. A negative storage value or a value above 65535 is invalid before digit decoding. This ordering prevents a malformed input from being silently truncated into a plausible 16-bit pattern.

For speed, zero maps to zero and 800 maps to 80. Values -1 and 801 are rejected. A fractional source value such as 355.5 is rejected because the source contract is an integer count of tenths. Dividing 355 using integer-only arithmetic and then converting the result would lose the half-unit; the expected target remains 35.5.

Source speed	Source count pattern	Enabled	Result
355	0125	true	Accept: 35.5, 125, true
0	0001	false	Accept: 0, 1, false
800	0500	true	Accept: 80, 500, true
355	001A	true	Reject invalid decimal digit
355	0501	true	Reject quantity above limit
355	0000	true	Reject zero quantity
801	0125	true	Reject speed above limit
355	0125	missing	Reject missing Boolean

The count column uses hexadecimal patterns, not decimal input strings. Include that notation in the test sheet. Otherwise, two learners can type different underlying numbers while believing they are testing the same row.

Detect partial updates and prove the unchanged fields

Suppose the current target recipe is speed 20, quantity 10 and enabled false. An incoming source record contains speed 355, an invalid count pattern 001A and enabled true. The required result is rejection, with the current target still 20, 10 and false.

An implementation that writes speed 35.5 before validating count has failed the all-or-nothing requirement. The count may remain 10 while speed has changed, producing a hybrid recipe that nobody approved. Checking only the rejection flag would miss that defect; compare every target field before and after the failed conversion.

Now submit a fully valid record with speed 355, count pattern 0125 and enabled true. The complete accepted target becomes 35.5, 125 and true. Submit the same valid record again and the target values remain the same. This test demonstrates deterministic value conversion, not a general claim about message delivery, duplicate suppression or exactly-once actions.

For round-trip assessment, encode every accepted quantity from one through 500 into packed decimal and decode it again. Each quantity must return unchanged. This verifies the chosen numerical mapping across its full allowed range. It does not prove that a target PLC's structure layout, byte order or external protocol matches the fictional record.

05

Keep equivalence tests separate from deliberate improvements

A migration often reveals code that could be clearer. Record whether a proposed change preserves behaviour or intentionally changes it. Renaming a symbol may be mostly structural; changing an invalid-input policy can alter application behaviour even if the new policy seems more sensible.

For the recipe exercise, preserving a quantity limit of 500 is part of equivalence. Increasing it to 600 is an expansion requiring a new requirement and new acceptance cases. Likewise, changing rejection into clamping would make an incoming quantity of 501 accepted as 500. That is a different policy, not merely a cleaner implementation.

Keep a baseline result set for the required source behaviour and a separate result set for approved changes. This makes a review easier: a failed baseline test must be explained by either a defect or an explicitly accepted requirement change. Without that separation, a migration can quietly accumulate unrelated modifications that are difficult to diagnose later.

For performance claims, measure the relevant task in a representative native environment. Do not infer a fixed speed improvement from a CPU family name or a clean compile. The S7-1200 and S7-1500 selection guide focuses on requirements and model-specific evidence rather than a universal multiplier.

Plan native validation and recovery as distinct work

A local arithmetic test validates the recipe model. A native test must additionally establish that declarations, conversions, calls and interfaces implement that model in the selected environment. Simulation can support part of that work, but its supported target and feature limits must match the project being tested.

Do not assume that every TIA installation includes every simulation product or that one simulator covers all CPU generations and communications. Ask the course provider which software, licence and target are used. A successful logical test does not establish physical network, module or instrument behaviour.

For an authorised practical migration, the responsible team needs an agreed change window, a recoverable baseline and explicit acceptance and rollback conditions. The recovery procedure should identify which configuration and values are restored and how their correctness is checked. This guide does not instruct readers to download an unverified conversion to a working plant.

Treat restart and value restoration as observable requirements. In the recipe example, the chosen starting recipe must be stated after each lifecycle event under test. Do not claim that every download necessarily overwrites all data or that every retained value necessarily survives. Use the target documentation and actual event-specific test evidence.

Choose training that produces a reviewable migration record

Ask a training provider for a source archive, a defined target, an example migration log and an assessment that includes unresolved items. The learner should explain at least one converted behaviour, one data-interface risk and one test that would detect an incorrect result. Merely reproducing a wizard sequence is an incomplete assessment of migration reasoning.

For South African teams maintaining existing systems, include the available software and supplier dependencies in the course enquiry. The cheapest classroom option may not address the installed platform. Use the PLC course cost guide to compare practical access, licences and follow-up support as well as tuition.

PLC data-type learning supports the representation checks in the recipe example. PLC program testing practice supports expected results and defect diagnosis. Keep those foundations distinct from native conversion work and supplier-supported commissioning.

A useful submission contains the route decision, inventory, unresolved dependencies, migration messages, test results and recovery assumptions. Our Siemens learning hub links the supporting topics, while TIA Portal basics helps learners who need orientation before reviewing a converted project.

06

Questions about STEP 7 Classic migration

Can TIA Portal V20 directly migrate my .s7p file?

Siemens documents a migration-tool step that creates an .am20 file. Integrated .s7p migration is no longer supported from V20. Check the instructions for the exact version in your route instead of following an older tutorial unchanged.

Does migration automatically replace an S7-300 with an S7-1500?

No. Moving the engineering project and migrating the PLC program to replacement hardware are distinct operations. The replacement device needs its own supported configuration and validation. A program conversion alone does not transfer every hardware relationship.

Is a clean migration log enough to accept the project?

No. Review the log, compile and test the required behaviour and interfaces. A log cannot establish that an external recipe value has the intended units or that a physical field connection works. Acceptance needs evidence matched to the actual requirements.

Why can copying a word change a recipe quantity?

A storage word may represent packed decimal digits rather than an ordinary binary integer. In the example, hexadecimal 0125 represents decimal digits 125 but equals binary integer 293. Identify the representation and validate the mapping before copying data.

Can I practise migration reasoning without a native project?

Yes, by writing conversion requirements and testing synthetic records such as the example here. Describe that work accurately as model-based preparation. It does not establish native project conversion, hardware experience or successful plant migration.