Hello all,

I would just bring to your attention the discussion I opened on GitHub https://github.com/cloudfoundry/bosh/issues/1601

I am looking for the best way to achieve that or the most valid reason why I should not even try it :)

Thanks and regards,
Michael

I guess technically a deployment is just a bunch of rows in the bosh Postgres database; if you move them them to another bosh then that bosh will think it owns those VMs.
At the same time, initially the VMs will still be listening to the original bosh nats & blobstore.
But perhaps on the new bosh you do a recreate of all vms in the deployment and it will replace all the settings on each vms so that they call home to the new bosh.
Somewhere above you'd remove the same rows from the old bosh director Postgres DB 
New bosh would need the blobs - the releases and compiled packages - but I guess they could be recreated if you did a "bosh deploy" rather than a "bosh recreate".
Conceptually it should be possible - it's just rows in a database and some blobs; and some VMs who need an attitude adjustment about who's the boss.
Dr Nic

If your deployment have zone1 and zone 2 jobs, the best, safest and
easiest way to achieve this is to remove Z2 job in manifest and perform
deploy in old bosh. Deploy Z2 job in new bosh. Repeat this for Zone 1 jobs.


On Mon, Feb 27, 2017 at 2:55 PM, Grifalconi, Michael <
michael.grifalconi(a)sap.com> wrote:

Hello all,



I would just bring to your attention the discussion I opened on GitHub
https://github.com/cloudfoundry/bosh/issues/1601



I am looking for the best way to achieve that or the most valid reason why
I should not even try it :)



Thanks and regards,

Michael