21-Dec-2017 04:00 - edited 29-Mar-2022 12:26
The older F5 BIG-IP Migration Assistant is deprecated and is replaced by F5 Journeys.
F5 Journeys App Readme @ Github
The F5® Journeys BIG-IP upgrade and migration utility is a tool freely distributed by F5 to facilitate migrating BIG-IP configurations between different platforms. F5 Journeys is a downloadable assistant that coordinates the logistics required to migrate a BIG-IP configuration from one BIG-IP instance to another.
JOURNEYS is an application designed to assist F5 Customers with migrating a BIG-IP configuration to a new F5 device and enable new ways of migrating.
It does a bunch of stuff:
Full config BIG-IP migrations are supported for software paths according to the following matrix:
F5 Journeys App manages the logistics of a configuration migration. The F5 Journeys App either generates or accepts a UCS file from you, prompts you for a destination BIG-IP instance, and manages the migration. The destination BIG-IP instance has a tmsh command that performs the migration from a UCS to a running system. F5 Journeys uses this tmsh command to accomplish the migration using the platform-migrate option (see more details K82540512) .
The F5 Journeys App prompts you to enter a source BIG-IP (or upload a UCS file), the master key password, and destination BIG-IP instance. Once the tool obtains this information, it allows you to migrate the source BIG-IP configuration to the destination BIG-IP instance either entirely or in a per-application depending what you choose.
F5 Journeys App Readme @ Github
Let us know if something went wrong. By reporting issues, you support development of this project and get a chance of having it fixed soon. Please use bug template available here and attach the journeys.log file from the working directory (
/tmp/journeys by default)
Ideas for enhancements are welcome here
For questions or further discussion please leave your comments below. Enjoy!
Awesome. Is support for other cloud providers planned?
How does the AWS integration work? I don't see an option to specify that as a destination.
AWS support is coming in early 2018. Other cloud platforms are also planned including Azure and Google. No firm dates yet.
Does it mean platform-migrate now support any BIGIP module?
previously, this feature supported only LTM migration.
Yes, platform-migrate on versions 12.1.3 or 13.1.0 or greater now supports all modules
Nice, the documentation doesn't say that the command existed before with such limitation. I hope it will be changed! it can help people who want to migrate to previous versions even if last versions are recommended.
I would have preferred that it be available before. I migrated a BigIP with LTM, AFM, ASM, APM last summer to version 13.0 to vCMP and I had to migrate without this option because of this limitation.
PK: A couple questions:
Stanislas: I will see about getting the documentation updated to mention the older version of platform-migrate in TMOS for older versions.
Thanks for the comments.
PK: Thanks, I will have our dev team look into this.
PK: thanks for the feedback, I'll do my best to reproduce and fix that issue for the next release. If you're able to provide the BIG-IP model and software version, that should be a big help in producing the repro.
Will: I tried adding below devices
Big-IP 4000 running 11.5.4,
vCMP guest running 12.1.2(w/ Latest HF) host is running 11.5.4(5250v),
Big-IP VE running 12.1.2..
All the above resulted in below error
Big-IP VE 13.1.0 was added to the list with no issues.
Ok thanks PK! Just one thing to note, the Migration Assistant won't be able to connect directly to the BIG-IP running 11.5.4 (it requires software versions 12.1 or greater), but it should be returning a more friendly notification so I'll get that fixed. If you'd like to migrate from an 11.5.4 config, the Migration Assistant 'archives' panel provides a tool for selecting a previously generated UCS from versions 11.1 or greater, which can then be used for migration. We'll get the TypeError issue fixed for next release- thanks again!
I dont see any software on github to download, is that something im wrong?
All im seeing .MD readle files.
Click on the zip or tar.gz links
yes,i did and unzipd those..all im seeing FAQ,README,SETUP and SUPPORT .md files and one folder with resources[ .png files].
This link should contain the executables for the tool:
Does that work for you?
I dont see any executable files, all it has just .md and .png file.
I apologize, I believe if you reload the page you should now see executables.
Thanks Jong,im able see now.
All in this thread -
I enabled Issues in the github repository:
If you run into any issues with the software itself, please file an issue at the url above, and we will do our best to address it.
I apologize for the confusion in this thread trying to track and respond to issues you have encountered.
I will also update the documentation to reference the github Issues rather than this article for support.
I tried using this for my source running 12.1.2 to my already licensed target running 12.1.3, and the tool hangs at one of the first steps, "Licensing target device". I did enter the registration key I copied from the target into the tool, and don't have ability to uncheck the "License Device" option. How do I make it work?
Hello, I had a little issue between 184.108.40.206 and 220.127.116.11. The tool complains the the 18.104.22.168 is oldest than 22.214.171.124, so I wasn't able to migrate from 126.96.36.199 to 188.8.131.52 VE. I suspect the build versions confuse the tool. :) Thanks
Hi Laurent, we added support for nth element versioning in release 1.0.3 ( https://github.com/f5devcentral/f5-big-ip-migration-assistant/releases/tag/v1.0.3 )- could you give that a try?
Rickwho and Laurent, we will look into these issues - I know it's a hassle, but is there any chance you can register these as issues in github for us? Tracking bugs in this thread is fraught with peril, and I wouldn't want to lose track of your problems.
I would enter them myself, but then I wouldn't want you to not know when they get updated.
The platform-migrate option causes the UCS loader to ignore configuration objects related to the following items: •Interfaces •Interface bundles •High availability (HA) groups •Trunks •Virtual Local Area Networks (VLANs) •Self IP addresses •Port mirroring •Certificates •Management IP and route •Traffic groups •Trust domains •Hardwired failover •Route domains •Layer 2 (L2) forwarding •Spanning Tree Protocol (STP)
Apparently, now is just ignores mgmt IP, mgmt route, interface and join object referencing interface.
Are there plans to fix this please.
Thanks for providing this tool. Unfortunately it doesn't work for me. During the migration process the first step is the license activation, but this process hangs without any message. After around 30 minutes I've stopped the process.
Additionally I cannot see the greater value in using this tool, instead of using UCS platform-migrate import. It would be awesome to have the chance of selecting the objects (or just the object types) which should be migrated, but it doesn't seem to work like this.
I tried using this tool to migrate from a viprion to a virtual edition. Viprion was running v12.1.1-HF2 and the VE was on v12.1.3.
Got a LACP error
Jul 16 18:56:13 localhost emerg load_config_files: "/usr/bin/tmsh -n -g load sys config partitions all platform-migrate" - failed. -- 01070687:3: Link Aggregation Control Protocol (LACP) is not supported on this platform. Unexpected Error: Loading configuration process failed.
This migration in particular had some partitions with route-domains and on the main screen I saw no VLAN from the other partitions. Just VLANs from de /Common.
I'm sorry to inform you that development of this tool has been put on hold for now. I'll update the article to reflect this fact.
An alternative to the Migration Assistant is to just follow the steps outlined in K82540512: Overview of the UCS archive platform-migrate option.
Yes, this is possible. The difference between `platform-migrate` and the migration tools is, that the tools supports migrating interfaces, using an assistant, while platform migrate will just omit all device-specific configuration, like interfaces and trunks.
If you modify docker compose file a little you can have the VM to expose the public ip address to connect to it.
In the docker compose file:
And In the .env file add:
If the docker compose ip just redeploy:
docker compose down
docker compose up -d