# Moving from legacy to new driver for Allen Bradley

**URL:** <https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452>\
**Category:** Ignition\
**Tags:** ignition81, vision\
**Created:** [January 10, 2023, 8:19pm UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452 "2023-01-10T20:19:52Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrews](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@andrews](https://forum.inductiveautomation.com/u/andrews)\
**Post date:** [January 10, 2023, 8:19pm UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452/1 "2023-01-10T20:19:52Z")

</div>

Hello,

We are upgrading some Allen Bradley processors which will require switching from the legacy driver to the drive for the newer versions.

The company historically has created new windows/projects/devices. And then swapped it all, change all tag paths manually. then re launch new project.

It just seems like a really bad way. Also I fell like nothing changes but the processor. So why test? Why the need for a new device name and to update all the tags.

Wouldn't it be easier to just pop in the new processor then delete and create new device with updated driver but same name. Then everything should work as long as the connection takes.

Any ideas appreciated thank you?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 10, 2023, 8:25pm UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452/2 "2023-01-10T20:25:37Z")

</div>

Will not work. The legacy drivers have different syntax wherever there are arrays.

However, you should not have to redo all of the windows and templates. Just the OPC tags. Export it all, run through regular-expression-based search and replace, and import them back in. The tag names themselves can stay the same.

---

<div class="post-metadata">

**Author:** ![andrews](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@andrews](https://forum.inductiveautomation.com/u/andrews)\
**Post date:** [January 10, 2023, 8:38pm UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452/3 "2023-01-10T20:38:33Z")

</div>

Thanks @pturmel , next question. Since I can't do this with production running.

Would it be best to setup a local gateway on host machine, make the changes and test, then when we put in the new one just upload the backup from the local host?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 10, 2023, 8:47pm UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452/4 "2023-01-10T20:47:13Z")

</div>

I would test on a complete separate network with a trial mode gateway (same version, same modules) and PLCs with new firmware.

- Take a gateway backup from production,
- Load into test environment,
- Export all tags from test,
- Search/replace OPC Item Path to new syntax on affected devices (note that you may be adjusting UDT parameters to get the desired item paths in some cases),
- Change drivers (delete old driver, make new with same name),
- Import updated tags (I would prune this to just the affected tags),
- Restart the test gateway,
- Validate.
- Adjust for bugs. Repeat validation until all works.
- Re-export affected tags.

Then, during a production outage, on the production gateway:

- Change drivers (delete old driver, make new with same name),
- Import updated tags (just the affected ones),
- Restart the production gateway

---

<div class="post-metadata">

**Author:** ![andrews](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@andrews](https://forum.inductiveautomation.com/u/andrews)\
**Post date:** [January 10, 2023, 10:50pm UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452/5 "2023-01-10T22:50:59Z")

</div>

@pturmel I appreciate the advice.

why would installing a gateway on my host machine be a bad idea? Or will my machine suffice as a test environment for this?

I'm no longer with my previous place of employment. And this new system has a lot more restrictions.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 11, 2023, 1:41am UTC](https://forum.inductiveautomation.com/t/moving-from-legacy-to-new-driver-for-allen-bradley/68452/6 "2023-01-11T01:41:07Z")

</div>

> [@andrews](#):
>
> on my host machine be a bad idea?

Because then the gateway can connect to anything your workstation/laptop can connect to, and that is usually undesirable (especially if your laptop normally can reach the production LAN).
