Did you read in this KB about the utility from VMware that can help preserve the ID? 

https://www.veeam.com/kb2136

Yes, but as I mentioned that this tool not supported with VBR v12.1!

That’a why I am asking if this tool still valid or there is another method that is supported by VBR 12 and higher !

Oh, sorry I got it now I did not notice the links below in that KB.

Thanks bro for your reply.

I read the links and tools that you mentioned all of them refer the migration from vCenter Windows to VCSA appliance as this is not the case as it is VCSA appliance 8 to newer updated VCSA 8 appliance!

From your experience will it work the same way ?

Unsure if it will work or not never used it.  Experimentation will be needed I think.

For now there is no official solution to migrate the MoRef IDs. Veeam is working on a new migration utility, which might be released for the latest VBR build in this year. 

Which vCenter Build are you currently running?

Some years ago, when we deployed for the very first time a VCSA instead of a windows based vCenter, we migrated data using a fling to do it, and we faced the same issue. We fixed it extracting the IDs of all the VMs from vcenter with powershell to a table and then modifying the Veeam database field for VM’s ID, matching VMs names….. probably it’s unsupported but it worked for us

vCenter Server 8.0 U2 Build 22385739

Ok then my idea doesn’t work for that case. If you were on an older major release, you could have upgraded your VCSA which replaces the whole appliance instead of building a new one. As an alternative, have you tried to restore your existing vCenter configuration into a new appliance and then try to update it? 

I haven’t encountered this issue yet since upgrading, but I’m sure I will so I’m looking forward to a method to recovery from vCenter failures as well.  That said, the current VCSA appliances seem to be much more reliable than the previous versions so it’s been a while since I’ve had to match up MoRef ID’s.  That said, in most cases for myself, starting new backup chains generally isn’t the end of the world, but annoying.  And all of that said, the utility previously published wasn’t actually supported, so while I never had an issue with it, it would be great to see something supported in the future.

I am not that sure if PowerShell Scripts can solve this case, but let me share the scripts that I will try it on Lab to figure it out and also if you have some comments or findings on these scripts as I am not that good with PowerShell yet it will be helpful.

1- Export the current list of VMs and their configurations from Veeam using PowerShell:

Get-VBRJob | ForEach-Object {
    $job = $_
    $vms = Get-VBRJobObject -Job $job
    $vms | Select-Object @{Name="JobName"; Expression={$job.Name}}, Name, Type, Path
} | Export-Csv -Path "C:\Backup\VeeamJobVMs.csv" -NoTypeInformation

2- automate the reconfiguration, use a PowerShell script to map old VMs to new VMs and update the Veeam jobs:

# Import the new vCenter
$newVC = Connect-VIServer -Server "new-vcenter.domain.com"

# Load the previously exported VM list
$oldVMList = Import-Csv -Path "C:\Backup\VeeamJobVMs.csv"

# Map old VMs to new VMs
$vmMapping = @{}
foreach ($oldVM in $oldVMList) {
    $newVM = Get-VM -Name $oldVM.Name -Server $newVC
    if ($newVM) {
        $vmMappingi$oldVM.Path] = $newVM
    }
}

Disconnect-VIServer -Server $newVC -Confirm:$false

# Connect to Veeam
Add-PSSnapin -Name VeeamPSSnapIn

# Iterate over each job and update VM references
foreach ($job in Get-VBRJob) {
    $jobObjects = Get-VBRJobObject -Job $job
    foreach ($jobObject in $jobObjects) {
        $oldPath = $jobObject.Path
        if ($vmMapping.ContainsKey($oldPath)) {
            $newVM = $vmMappingi$oldPath]
            Remove-VBRJobObject -Job $job -Object $jobObject -Confirm:$false
            Add-VBRViJobObject -Job $job -Entities $newVM
        }
    }
}

I will give it a try and let me know if you notice something too.

Thanks

Let us know how the scripts work cause it could be a workaround for others.

For me it would be quite bad. With monster VM’s  and many 100’s of TB’s of data, takes a long time to backup. If I had to do a full backup on everything it takes an extremely long time.  The last time I did something like this I’d migrate 1 at a time and let the full run before moving on to the next. 

Hi All,

I am sorry that the work around did not work, I tried lot to figure it out but without any luck.

I Hope that Veeam or VMWare give us a valid tool to achieve that as before.

Thanks for everyone who tried to help in this issue.

Sorry to hear the scripts did not work as it looked promising.  Hopefully someone will come out with a tool like the previous one that fixes this.

@Madi.Cristil @safiya - since it seems this thread does not have a true answer maybe we convert it to discussion instead of a question.

Hi all

We plan to bring back this utility with a product release in 2024 H2.

Best,

Fabian

Hi community

The tool was updated one week ago:

• requires v12.2 or later
• works with PostgreSQL and MSSQL configuration database

KB2136: Veeam VM Migrator Tool

Best,

Fabian

That’s a great news, thank you Fabian!

Nice to see the tool updated. Used a few times and works great. 

didn’t even know about this. Very nice, that there is a tool for this. Had some customers in the past, which lost their VCSA or moved to a new one (without migration), so they started new backup chains. Thanks!