Service 'PackageRepository' cannot be migrated because the specified service is not installed locally.

[OSZF]

I'm trying to create a backup of our SystemLink 21.0 Server and try to restore it to a new SystemLink 2022 Q1 on a other machine but when doing this I'm receiving the Error:

C:\Program Files (x86)\Python310-32\Scripts>nislmigrate.exe restore --all -f --secret=#### --dir=C:\Users\Public\Documents\####
[2022-12-01 15:30:16] Performing pre-migration check for AlarmInstance
[2022-12-01 15:30:16] Pre-migration check passed for AlarmInstance.
[2022-12-01 15:30:16] Performing pre-migration check for AssetPerformanceManagement
[2022-12-01 15:30:16] Pre-migration check passed for AssetPerformanceManagement.
[2022-12-01 15:30:16] Performing pre-migration check for AssetPerformanceManagementRuleEngine
[2022-12-01 15:30:16] Pre-migration check passed for AssetPerformanceManagementRuleEngine.
[2022-12-01 15:30:16] Performing pre-migration check for DocumentManager
[2022-12-01 15:30:16] Pre-migration check passed for DocumentManager.
[2022-12-01 15:30:16] Performing pre-migration check for FileIngestion
[2022-12-01 15:30:16] Pre-migration check passed for FileIngestion.
[2022-12-01 15:30:16] Performing pre-migration check for Notification
[2022-12-01 15:30:16] Pre-migration check passed for Notification.
[2022-12-01 15:30:16] Performing pre-migration check for PackageRepository
[2022-12-01 15:30:16] FileNotFoundError: Could not find the captured service at C:\Users\Public\Documents\####\PackageRepository\PackageRepository

So this is for me the indication that the capture went wrong.

But when I now try to backup only the repos with I receive the fallowing error:
C:\WINDOWS\system32>nislmigrate capture --repo --secret=#### --dir=C:\Users\####\Desktop\####
[2022-12-01 15:19:30] MigrationError:
Service 'PackageRepository' cannot be migrated because the specified service is not installed locally.
Remove unavailable services from the request and try again, or use --all to request all supported services
that are currently installed..

1. I could not find any option how to update or install the Service 'PackageRepository'.
2. I have installed the most current version of nislmigrate 1.1.0 and are using Python 3.8.0
3. Is this a Bug or what am I doing wrong?

[Christian-Nunnally]

The migration tool is giving you that message because PackageRepository.json doesn't exist within the configuration file directory, which does indicate that you don't have the pakcage repository service installed. Are you sure you have that service installed? If there are files to migrate related to the PackageRepository service, they would be located at C:\\Program Files\\National Instruments\\Shared\\Web Services\\NI\\repo_webservice\\files

If PackageRepository is simply not installed and doesn't need to be migrated, you can run the tool excluding the --repo flag, but including all of the other flags you do want to include, like --tags ... etc etc ... --files --security --secrect=*****

[NurAb-Sal]

The problem is that the service definition .json below %PROGRAMDATA%/National Instruments/Skyline/Config/Repository.json does not match nislmigrate's RepositoryMigrator.name property value "PackageRepository" which hence fails to identify the service correctly. I wonder when that service got renamed.

I have submitted Pull Request #148 to amend this issue.

[Christian-Nunnally]

I left this comment on the PR also, but perhaps creating a copy of Repository.json and renaming it to PackageRepository.json would fix the issue, the format of the file should be the same.

[OSZF]

Hi @Christian-Nunnally and thank you for the quick response.

So @NurAb-Sal as our NI Field Engineer helped me already to get this working by renaming in repository_migrator.py:
class RepositoryMigrator(MigratorPlugin):
@Property
def name(self):
return 'Repository'

But of cause this must be fixed in the source code here on git as well.

But now I have the same issue with Systemstates:
C:\WINDOWS\system32>nislmigrate capture --systemstates --secret=#### --dir=C:\Users\####\Desktop\####
[2022-12-01 17:23:34] MigrationError:
Service 'SystemsState' cannot be migrated because the specified service is not installed locally.
Remove unavailable services from the request and try again, or use --all to request all supported services
that are currently installed.

And the problem now is that non such corresponding SystemsState.json exists in C:\ProgramData\National Instruments\Skyline\Config There are only SystemsManagement.json and SystemsStateManager.json

1. What would you suggest to get this fixed @Christian-Nunnally
2. Will the SystemState migration even work from SystemLink 21.0 Server to 2022 Q1?

[Christian-Nunnally]

By changing the name that the migrator returns, you're going to need to make sure that you rename the json file after restore to PackageRepostory.json. Alternatively leaving the code unchanged and creating a copy of the file named PackageRepository.json will also work.

As far as system states migration from 2020 to 2022 that is untested, however you could attempt the same remedy we're doing for the package repo service and copy and rename SystemsStateManager.json to SystemsState.json. The data stored in mongo db for the systems state service should migrate okay. The other thing the migration tool does for that service is copy the contents of %ProgramData%/National Instruments/Skyline/Data/SystemsStateManager/States, so you might check to make sure that directory exists, and if it does, then its very likely the only thing that changed here is the service name.

[OSZF]

Hi @Christian-Nunnally so the change worked you suggested SystemsStateManager.json to SystemsState.json but the problem is that no SystemsState folder is created and I receive a KeyError:

C:\WINDOWS\system32>nislmigrate capture --systemstates --secret=####--dir=C:\Users\####\Desktop\####
[2022-12-02 08:53:19] Performing pre-migration check for SystemsState
[2022-12-02 08:53:19] Pre-migration check passed for SystemsState.
[2022-12-02 08:53:19] Stopping all SystemLink services...
[2022-12-02 08:53:35] Starting to capture data using ('capture', 'SystemsState') migrator strategy ...
[2022-12-02 08:53:35] Starting all SystemLink services...
[2022-12-02 08:53:37] KeyError: 'SystemsState'

1. How to fix this KeyError

[Christian-Nunnally]

Hi @Christian-Nunnally so the change worked you suggested SystemsStateManager.json to SystemsState.json but the problem is that no SystemsState folder is created and I receive a KeyError:

C:\WINDOWS\system32>nislmigrate capture --systemstates --secret=####--dir=C:\Users####\Desktop#### [2022-12-02 08:53:19] Performing pre-migration check for SystemsState [2022-12-02 08:53:19] Pre-migration check passed for SystemsState. [2022-12-02 08:53:19] Stopping all SystemLink services... [2022-12-02 08:53:35] Starting to capture data using ('capture', 'SystemsState') migrator strategy ... [2022-12-02 08:53:35] Starting all SystemLink services... [2022-12-02 08:53:37] KeyError: 'SystemsState'

1. How to fix this KeyError

Oh, the service name is also defined inside the .json file. In your copied files, rename SystemsStateManager to SystemsState

[OSZF]

Hi @Christian-Nunnally as I understand from your last post SystemsStateManager & SystemsState is creating the same export of data is this correct?
Because if so it should be able to rename on the target system the created SystemsStateManager to SystemsState and it should work right?

Command Line with "SystemsStateManager" Folder name in the capture folder:
C:\Program Files (x86)\Python310-32\Scripts>nislmigrate.exe restore --all -f --secret=#### --dir=C:\Users\Public\Documents####
[2022-12-01 17:19:00] Performing pre-migration check for AlarmInstance
[2022-12-01 17:19:00] Pre-migration check passed for AlarmInstance.
[2022-12-01 17:19:00] Performing pre-migration check for AssetPerformanceManagement
[2022-12-01 17:19:00] Pre-migration check passed for AssetPerformanceManagement.
[2022-12-01 17:19:00] Performing pre-migration check for AssetPerformanceManagementRuleEngine
[2022-12-01 17:19:00] Pre-migration check passed for AssetPerformanceManagementRuleEngine.
[2022-12-01 17:19:00] Performing pre-migration check for DocumentManager
[2022-12-01 17:19:00] Pre-migration check passed for DocumentManager.
[2022-12-01 17:19:00] Performing pre-migration check for FileIngestion
[2022-12-01 17:19:00] Pre-migration check passed for FileIngestion.
[2022-12-01 17:19:00] Performing pre-migration check for Notification
[2022-12-01 17:19:00] Pre-migration check passed for Notification.
[2022-12-01 17:19:00] Performing pre-migration check for PackageRepository
[2022-12-01 17:19:00] Pre-migration check passed for PackageRepository.
[2022-12-01 17:19:00] Performing pre-migration check for Security
[2022-12-01 17:19:00] Pre-migration check passed for Security.
[2022-12-01 17:19:00] Performing pre-migration check for SystemsState
[2022-12-01 17:19:00] FileNotFoundError: Could not find the captured service at C:\Users\Public\Documents####\SystemsState\SystemsState

Command Line with "_SystemsState _" Folder name in the capture folder:
C:\Program Files (x86)\Python310-32\Scripts>nislmigrate.exe restore --all -f --secret=####--dir=C:\Users\Public\Documents####
[2022-12-05 08:45:34] Performing pre-migration check for AlarmInstance
[2022-12-05 08:45:34] Pre-migration check passed for AlarmInstance.
[2022-12-05 08:45:34] Performing pre-migration check for AssetPerformanceManagement
[2022-12-05 08:45:34] Pre-migration check passed for AssetPerformanceManagement.
[2022-12-05 08:45:34] Performing pre-migration check for AssetPerformanceManagementRuleEngine
[2022-12-05 08:45:34] Pre-migration check passed for AssetPerformanceManagementRuleEngine.
[2022-12-05 08:45:34] Performing pre-migration check for DocumentManager
[2022-12-05 08:45:34] Pre-migration check passed for DocumentManager.
[2022-12-05 08:45:34] Performing pre-migration check for FileIngestion
[2022-12-05 08:45:34] Pre-migration check passed for FileIngestion.
[2022-12-05 08:45:34] Performing pre-migration check for Notification
[2022-12-05 08:45:34] Pre-migration check passed for Notification.
[2022-12-05 08:45:34] Performing pre-migration check for PackageRepository
[2022-12-05 08:45:34] Pre-migration check passed for PackageRepository.
[2022-12-05 08:45:34] Performing pre-migration check for Security
[2022-12-05 08:45:34] Pre-migration check passed for Security.
[2022-12-05 08:45:34] Performing pre-migration check for SystemsState
[2022-12-05 08:45:34] Pre-migration check passed for SystemsState.
[2022-12-05 08:45:34] Performing pre-migration check for SystemsManagement
[2022-12-05 08:45:34] FileNotFoundError: Could not find the captured service at C:\Users\Public\Documents####\SystemsManagement\SystemsManagement

So as you can see the restore function is expecting a separat "SystemsStateManager" AND "SystemsState" folder to be created by the capture command on the original server.
So just renaming "SystemsStateManager" to "SystemsState" should not be valide as I understand from this... or do I' getting it wrong?

1. How can we continue now and when this stuff will be fixed in the nislmigrate tool directly?

[OSZF]

Hi @Christian-Nunnally sorry for making pressure but we really need a quick solution for the migration...
If you have any questions regarding impact etc. please reach out to Reinhard Fuchs who is our Global Account Manager.

[OSZF]

@Christian-Nunnally do you have a solution or answer for me?

[Christian-Nunnally]

Hi @Christian-Nunnally as I understand from your last post SystemsStateManager & SystemsState is creating the same export of data is this correct? Because if so it should be able to rename on the target system the created SystemsStateManager to SystemsState and it should work right?

Command Line with "SystemsStateManager" Folder name in the capture folder: C:\Program Files (x86)\Python310-32\Scripts>nislmigrate.exe restore --all -f --secret=#### --dir=C:\Users\Public\Documents#### [2022-12-01 17:19:00] Performing pre-migration check for AlarmInstance [2022-12-01 17:19:00] Pre-migration check passed for AlarmInstance. [2022-12-01 17:19:00] Performing pre-migration check for AssetPerformanceManagement [2022-12-01 17:19:00] Pre-migration check passed for AssetPerformanceManagement. [2022-12-01 17:19:00] Performing pre-migration check for AssetPerformanceManagementRuleEngine [2022-12-01 17:19:00] Pre-migration check passed for AssetPerformanceManagementRuleEngine. [2022-12-01 17:19:00] Performing pre-migration check for DocumentManager [2022-12-01 17:19:00] Pre-migration check passed for DocumentManager. [2022-12-01 17:19:00] Performing pre-migration check for FileIngestion [2022-12-01 17:19:00] Pre-migration check passed for FileIngestion. [2022-12-01 17:19:00] Performing pre-migration check for Notification [2022-12-01 17:19:00] Pre-migration check passed for Notification. [2022-12-01 17:19:00] Performing pre-migration check for PackageRepository [2022-12-01 17:19:00] Pre-migration check passed for PackageRepository. [2022-12-01 17:19:00] Performing pre-migration check for Security [2022-12-01 17:19:00] Pre-migration check passed for Security. [2022-12-01 17:19:00] Performing pre-migration check for SystemsState [2022-12-01 17:19:00] FileNotFoundError: Could not find the captured service at C:\Users\Public\Documents####\SystemsState\SystemsState

Command Line with "_SystemsState _" Folder name in the capture folder: C:\Program Files (x86)\Python310-32\Scripts>nislmigrate.exe restore --all -f --secret=####--dir=C:\Users\Public\Documents#### [2022-12-05 08:45:34] Performing pre-migration check for AlarmInstance [2022-12-05 08:45:34] Pre-migration check passed for AlarmInstance. [2022-12-05 08:45:34] Performing pre-migration check for AssetPerformanceManagement [2022-12-05 08:45:34] Pre-migration check passed for AssetPerformanceManagement. [2022-12-05 08:45:34] Performing pre-migration check for AssetPerformanceManagementRuleEngine [2022-12-05 08:45:34] Pre-migration check passed for AssetPerformanceManagementRuleEngine. [2022-12-05 08:45:34] Performing pre-migration check for DocumentManager [2022-12-05 08:45:34] Pre-migration check passed for DocumentManager. [2022-12-05 08:45:34] Performing pre-migration check for FileIngestion [2022-12-05 08:45:34] Pre-migration check passed for FileIngestion. [2022-12-05 08:45:34] Performing pre-migration check for Notification [2022-12-05 08:45:34] Pre-migration check passed for Notification. [2022-12-05 08:45:34] Performing pre-migration check for PackageRepository [2022-12-05 08:45:34] Pre-migration check passed for PackageRepository. [2022-12-05 08:45:34] Performing pre-migration check for Security [2022-12-05 08:45:34] Pre-migration check passed for Security. [2022-12-05 08:45:34] Performing pre-migration check for SystemsState [2022-12-05 08:45:34] Pre-migration check passed for SystemsState. [2022-12-05 08:45:34] Performing pre-migration check for SystemsManagement [2022-12-05 08:45:34] FileNotFoundError: Could not find the captured service at C:\Users\Public\Documents####\SystemsManagement\SystemsManagement

So as you can see the restore function is expecting a separat "SystemsStateManager" AND "SystemsState" folder to be created by the capture command on the original server. So just renaming "SystemsStateManager" to "SystemsState" should not be valide as I understand from this... or do I' getting it wrong?

1. How can we continue now and when this stuff will be fixed in the nislmigrate tool directly?

It looks like you resolved the issue with the SystemsState service and and now facing new issue with the SystemsManagement service, which is a separate service. I'm not sure why it's not finding SystemsManagement.json though because you mentioned that it existed on the original server right? Did it not get captured for some reason? If SystemsManagement.json is not in the capture folder, double check it was on the original server, was that one of the things that got renamed?

This tool is open source with a contributing guide, if you want to add support for 20.0 migrations a new version can be released at any time, my recommended approach for fixing would be to add a flag that modifies the behavior of the renamed exporters using this function:

NI-SystemLink-Migration/nislmigrate/extensibility/migrator_plugin.py

Line 194 in 0fb6db3

def add_additional_arguments(self, argument_manager: ArgumentManager) -> None:

[OSZF]

Hi @Christian-Nunnally this is everything what gets created by the command "capture --all":

Hi @Christian-Nunnally so the change worked you suggested SystemsStateManager.json to SystemsState.json but the problem is that no SystemsState folder is created and I receive a KeyError:
C:\WINDOWS\system32>nislmigrate capture --systemstates --secret=####--dir=C:\Users####\Desktop#### [2022-12-02 08:53:19] Performing pre-migration check for SystemsState [2022-12-02 08:53:19] Pre-migration check passed for SystemsState. [2022-12-02 08:53:19] Stopping all SystemLink services... [2022-12-02 08:53:35] Starting to capture data using ('capture', 'SystemsState') migrator strategy ... [2022-12-02 08:53:35] Starting all SystemLink services... [2022-12-02 08:53:37] KeyError: 'SystemsState'
1. How to fix this KeyError

Oh, the service name is also defined inside the .json file. In your copied files, rename SystemsStateManager to SystemsState

1. In which .json file exactly I need to rename SystemsStateManager to SystemsState? To resolve the KeyError?

[Christian-Nunnally]

Command Line with "_SystemsState _" Folder name in the capture folder:
C:\Program Files (x86)\Python310-32\Scripts>nislmigrate.exe restore --all -f --secret=####--dir=C:\Users\Public\Documents#### [2022-12-05 08:45:34] Performing pre-migration check for AlarmInstance [2022-12-05 08:45:34] Pre-migration check passed for AlarmInstance. [2022-12-05 08:45:34] Performing pre-migration check for AssetPerformanceManagement [2022-12-05 08:45:34] Pre-migration check passed for AssetPerformanceManagement. [2022-12-05 08:45:34] Performing pre-migration check for AssetPerformanceManagementRuleEngine [2022-12-05 08:45:34] Pre-migration check passed for AssetPerformanceManagementRuleEngine. [2022-12-05 08:45:34] Performing pre-migration check for DocumentManager [2022-12-05 08:45:34] Pre-migration check passed for DocumentManager. [2022-12-05 08:45:34] Performing pre-migration check for FileIngestion [2022-12-05 08:45:34] Pre-migration check passed for FileIngestion. [2022-12-05 08:45:34] Performing pre-migration check for Notification [2022-12-05 08:45:34] Pre-migration check passed for Notification. [2022-12-05 08:45:34] Performing pre-migration check for PackageRepository [2022-12-05 08:45:34] Pre-migration check passed for PackageRepository. [2022-12-05 08:45:34] Performing pre-migration check for Security [2022-12-05 08:45:34] Pre-migration check passed for Security. [2022-12-05 08:45:34] Performing pre-migration check for SystemsState [2022-12-05 08:45:34] Pre-migration check passed for SystemsState. [2022-12-05 08:45:34] Performing pre-migration check for SystemsManagement [2022-12-05 08:45:34] FileNotFoundError: Could not find the captured service at C:\Users\Public\Documents####\SystemsManagement\SystemsManagement

It looks like you had it working in your above example ^ but it was having issue with SystemsManagement. I see you have a SystemsManagement directory in your capture folder, what's inside? What is the name of the json file inside? and what are the (with sensitive information redacted) contents of SystemsManagement.json if it exists?

[OSZF]

Hi @Christian-Nunnally here is the content of the SystemsManagement directory:

And this not seams to be json file at all because they have no ending as well when I open them with notepad++ the content is not human readable.

And it only worked for PackageRepository but not for SystemsStateManager or SystemsState because them seams to be different exports at all and both needed for the import!

[OSZF]

Hi @Christian-Nunnally with the help of @NurAb-Sal I could finally get the capture for the SystemsManagement & SystemsStateManager working by renaming things like this:

After this change I could execute the C:\WINDOWS\system32>nislmigrate capture --systems --secret=#### --dir=C:\Users\###\Desktop\#### command successfully!

BUT now as I wanted to create a full capture with capture --all I received KeyError: 'PackageRepository'

And I can reproduce this also by just running capture --repo:
C:\WINDOWS\system32>nislmigrate capture --repo --secret=#### --dir=C:\Users\svc.ksc.jenkins\Desktop####
[2022-12-21 16:55:48] Performing pre-migration check for PackageRepository
[2022-12-21 16:55:48] Pre-migration check passed for PackageRepository.
[2022-12-21 16:55:48] Stopping all SystemLink services...
[2022-12-21 16:56:08] Starting to capture data using ('capture', 'PackageRepository') migrator strategy ...
[2022-12-21 16:56:08] Starting all SystemLink services...
[2022-12-21 16:56:10] KeyError: 'PackageRepository'

@NurAb-Sal explained me that this KeyError is coming from the MongoDB but he can't help me on that without any detailed knowledge about you application and this DB.

So I kindly ask you to help me fixing this issue @Christian-Nunnally.

[OSZF]

@Christian-Nunnally do you have any updated?
We still need a valide full working nislmigrate tool which also migrated all Test Module DB entry's to the new Server.

[Christian-Nunnally]

@OSZF I'm so sorry, I didn't mean to leave you hanging after the holidays! This issue dropped off my radar, and I haven't been getting notifications from this repo.

The content of the SystemsManagement file is the MongoDB dump file, which is why it's not human readable.
The last error you're seeing on PackageRepository is likely due to the contents of PackageRepository.json still containing the top level key "Repository". I suggest creating a copy of what was orignally named Repository.json (and you have since renamed to PackageRepository.json). Leave the original as is, and do two things to the copy:

1. Rename it to PackageRepository.json
2. Open the newly renamed PackageRepository.json in a text editor and rename Repository to PackageRepository

I suggest going through similar steps to make sure you have a SystemsState.json and SystemsManagement.json with the corresponding top level keys in the json ("SystemsState" and "SystemsManagement"), so that you can get a capture --all --secrect *** working /without/ modifying the migrators source code.

If you capture after changing the name returned by the migrator, you will need ensure you do the restore with the same modified migrator and you will need to rename the migrated files and contents following step 1 and 2 after restore. Since you have to modify the cofiguration files with either strategy, that's why I suggest not changing the source code of the migrator in the way you have before capturing.

[OSZF]

Hi @Christian-Nunnally,
thank you for your response :-) I will need to test this when we will be migrating to the next system server which will happen in a view weeks as I think where we must migrate also the Test Module DB.

But regarding the NI-SystemLink-Migration Tool when will this be properly updated by NI to not must be using all this Workarounds above??? Because it's written in the official Docu that SystemLink 21.0 is support but we see its not because its not working without al this huge effort and help....
And together with @NurAb-Sal and a other NI Support Engineer from NI Munich we discovered that the official NI-SystemLink-Migration Doku is just incorrect and must be updated as well because it was not maintained: For example the Argument Flag "--tests" is not named "--tests" anymore!

[Christian-Nunnally]

Hi @Christian-Nunnally, thank you for your response :-) I will need to test this when we will be migrating to the next system server which will happen in a view weeks as I think where we must migrate also the Test Module DB.

But regarding the NI-SystemLink-Migration Tool when will this be properly updated by NI to not must be using all this Workarounds above??? Because it's written in the official Docu that SystemLink 21.0 is support but we see its not because its not working without al this huge effort and help.... And together with @NurAb-Sal and a other NI Support Engineer from NI Munich we discovered that the official NI-SystemLink-Migration Doku is just incorrect and must be updated as well because it was not maintained: For example the Argument Flag "--tests" is not named "--tests" anymore!

The migration tool was manually tested against fresh installs of the versions of SL listed on the read me, I think the reason there are so many work arounds needed here is that the server you're migrating from was previously upgraded from an earlier version, if that is the case, that was not tested. Can you confirm the history of the server you're migrating from and whether it was originally installed as a 21.0 server or was previously upgraded in place?

[OSZF]

Hi @Christian-Nunnally not that is defiantly not the case.
Our Server was installed as SystemLink 21.0 from the beginning on and I did this so I know it 100%!

This means for me now the tool was never relay tested with SystemLink 21.0 because otherwise it should work as you just explained by yourself. And also the documentation in not matching the current version of the tool as we found out with @NurAb-Sal as I wrote on the top.

So again my question:
When will this updates/maintenance be done and the documentation updated so a customer is able to use it properly for the current available SystemLink Versions?

[Christian-Nunnally]

@OSZF Since you're migrating from a 'freshly' installed 21.0 I'm not sure how this didn't get caught during the manual testing. If the tool failed in this way the test would have failed, so you're right that that indicates manual tests weren't done against a clean 21.0 server. I added the documentation on which versions are supported and did a lot of the manual testing, maybe I incorrectly documented 21.0 when 21.1 was the oldest version tested against, but that just doesn't sound right because there were four versions we tested against and 22 was not out yet.

When I have time I can re-run the manual tests against a 21.0 server to validate what we're saying here. Then I can update the documentation to remove the claimed 21.0 support if it doesn't work. Adding support for the SystemsManagement and PackageRepository migrators to look for the configuration file in one of two places would be a potential 'fix' but the restore would need to know how to rename and edit the file after restore depending on which version you're restoring to. This could be done by adding a command line argument to both of these migrators that specifies the version being migrated to/from

NI-SystemLink-Migration/nislmigrate/extensibility/migrator_plugin.py

Line 37 in 43fde48

def add_argument(self, name: str, help: str, metavar: str) -> None:

. Renaming the migrator as @NurAb-Sal did will only work for 21.0 and manually editing will still be required on restore.

I can implement a potential fix for your 21.0 migration and provide it to you in a branch as a one off, as that would only take a couple of hours, but it would be untested.

I've updated the documentation for the --testmonitor migrator.

[JD-Robertson]

I think the documentation may just be wrong. We did test 21.0 during development and ran into these problems. My recollection is that we decided to simply not support this use case. It's possible that didn't get reflected in the documentation.

[OSZF]

Hi @JD-Robertson so you mean you saw all this issues already and didn't want to support SystemLink 21.0? did I got this right?
SystemLink is a current and salled NI Product and customers are using it and are reliant on a working and up to date migration tool.
So what is planed to bring up the support for this migration tool until the newest SystemLink version?
FYI: @NurAb-Sal

[OSZF]

Hi @JD-Robertson & @Christian-Nunnally do you have any updated for me?

Next week we will NEED to migrate the full SystemLink Server together with the testmonitor stuff as well which didn't work bevor as you know!