Migrating CompactLogix L32E/L35E to 5370 or 5380
Plan a CompactLogix L32E or L35E migration by separating controller conversion from I/O replacement, then validating firmware, communications, motion, panel space, and commissioning evidence.
Replacing a CompactLogix 1769-L32E or 1769-L35E is not a one-line controller substitution. The project combines controller compatibility, local I/O architecture, software revision, Ethernet behavior, serial requirements, panel layout, safety review, and production commissioning. Selecting a newer catalog number before documenting those dependencies can turn an emergency spare replacement into an unplanned controls redesign.
The central decision is whether the existing 1769 Compact I/O and field wiring must remain. A 5370-family controller can provide a lower-disruption path for many 1769 architectures. A 5380 platform moves the system to a newer controller and Compact 5000 I/O architecture, which can provide longer lifecycle value but requires broader engineering work.

Choose the migration path from the installed I/O, communications, motion, safety, and panel constraints rather than memory size alone.
Inventory the Existing System Before Choosing a Target
Start from an offline project and a physical survey. Record the exact controller catalog number, series, firmware revision, project revision, memory use, local I/O modules, expansion-bank arrangement, power supplies, communication ports, produced and consumed tags, explicit messages, HMI drivers, motion axes, and any third-party modules.
Compare the project with the installed panel. Legacy systems often contain undocumented substitutions or wiring changes. Photograph module order, terminal markings, network connections, status indicators, and panel clearances. Save the original project read-only and export tag, module, and cross-reference reports before changing the controller type.
Identify dependencies that do not appear as ordinary ladder logic. These can include controller status words, message paths, socket services, serial protocols, electronic keying, add-on profiles, vendor instructions, data logging, and external devices that expect a particular IP address or connection behavior.
Understand the 5370 Retention Path
A 5370 L3 controller is often considered when the plant wants to retain a 1769 Compact I/O architecture. This can reduce field rewiring and panel reconstruction, but it is not a drop-in guarantee. The selected controller must support the installed module count, bank layout, communication requirements, task loading, memory use, and software revision.
Controller memory should include realistic growth margin. Matching the current project’s used bytes is not enough when the migration also adds diagnostics, produced tags, newer module profiles, or revised HMI data. Verify capacity and supported features against the exact catalog number and firmware rather than relying on a family-level memory comparison.
Confirm whether the legacy project uses a serial port. L32E and L35E installations may depend on DF1, ASCII, Modbus through an interface, or a maintenance connection. A replacement controller without the same physical port requires a separately engineered gateway or network strategy. Treat this as a functional requirement, not an accessory decision.
If a plant intends to keep a high-memory spare, verify the spare against every machine project before declaring it universal. Store an approved converted project for each machine. A controller-type change, firmware mismatch, or communication-path difference can prevent a fast recovery even when memory capacity is sufficient.
Understand the 5380 Modernization Path
CompactLogix 5380 uses the 5069 platform and Compact 5000 I/O for its local architecture. It should be treated as a modernization project rather than a simple replacement for a local 1769 rack. Rockwell’s current CompactLogix 5380 documentation identifies the applicable controller manuals, specifications, and migration resources.
The 5380 path can add performance, capacity, security functions, and newer communication options. Those benefits must be evaluated against new terminal assemblies, power distribution, I/O module selection, panel dimensions, heat, grounding, network design, and commissioning time.
Map every 1769 module to a verified 5069 function. Similar channel counts do not prove equivalent behavior. Compare electrical input type, isolation, current limits, diagnostic features, data format, update time, fault state, electronic keying, terminal arrangement, and any channel-specific configuration. Specialty modules require additional review.
The active 5069-L320ER product page provides one hardware reference, while the PLC and PAC systems collection supports broader controller comparison. Final selection must still use the official manual and the project’s verified requirements.
Do Not Treat Program Conversion as Commissioning
Logix Designer may convert a project to another controller type, but a successful conversion only proves that the software created a project. Review conversion messages and changed module definitions. Confirm unsupported instructions, controller-scoped tags, data types, task periods, produced and consumed connections, motion configuration, and message paths.
Firmware and software must be planned together. Rockwell’s compatibility tools and release notes should be checked for the target controller, firmware, Logix Designer version, add-on profiles, and supporting communication software. Do not flash hardware at the machine until the approved combination and recovery method are documented.
Retain the original IP plan unless the network redesign is intentional. Verify duplicate-address protection, subnet, gateway, switch configuration, ring participation, multicast behavior, HMI shortcuts, historian connections, and remote access. A controller that runs ladder logic but cannot exchange data with the rest of the cell is not a completed migration.
Engineer I/O and Panel Changes Explicitly
For a retained 1769 architecture, inspect power-supply capacity, module spacing, expansion cables, end caps, and bank rules. A controller replacement is a good opportunity to find weak terminals, obsolete specialty modules, and undocumented interlocks, but unrelated changes should be controlled rather than folded into the project without review.
For a 5069 conversion, create new panel drawings and terminal plans. Check wire length, conductor size, common grouping, shield termination, field power, removable terminal blocks, fusing, and spare channels. Review temperature and spacing requirements using the exact installation instructions. Do not assume the new assembly occupies the same rail length or uses the same field common arrangement.
Safety functions require a separate assessment. If safety relays, GuardLogix, safe motion, or protective devices are involved, confirm the applicable safety lifecycle, signatures, validation records, and change-control requirements. A standard controller migration must not silently alter the safety function.
Build a Test Plan Before the Outage
Bench-stage the target controller where practical. Load the converted project, establish communications, verify firmware, and test representative I/O or simulated signals. Confirm HMI and engineering workstation connections. Record expected module identities and diagnostic states.
Prove Logic and Data Integrity
Compare critical tag values, scaling, timers, counters, sequence states, recipes, retained data, alarm thresholds, and startup initialization. Test power cycling and mode changes. Confirm that any first-scan or recovery logic behaves as intended with the new controller.
Prove Every External Interface
Test HMI commands, displayed values, alarms, historians, drives, remote I/O, messages, serial devices, produced and consumed tags, and maintenance access. Verify network timeout and fault behavior rather than checking only normal operation.
Prove the Physical Process
Commission outputs under controlled conditions. Check direction, fail state, interlocks, limits, and feedback. Run the machine through representative modes and production rates. Capture a signed test record and preserve a rollback plan until acceptance is complete.
Select the Path From Lifecycle Risk
A 5370 migration can reduce immediate disruption when the installed 1769 system and field wiring retain substantial value. A 5380 migration is usually the stronger long-term choice when the panel, I/O, communications, or safety design already requires major work. Neither path should be selected from a replacement chart alone.
The best migration separates urgent availability risk from planned modernization. Document the installed system, validate the exact target combination, stage the conversion, and prove every interface. That approach turns an obsolete-controller problem into a controlled lifecycle project.