We are German ISV and SI partners and I noticed that at one of our clients Org we received a Sandbox on cs17.
Earlier we had an full copy sandbox for staging and UAT but now we were able to set up a repeatable ETL Process to maintain a sufficient environment on a free developer sandbox which saves quite an significant amount of the clients budget. The full copy boxes usually spun at cs18.
Neither the client nor we as consultants ever requested a prerelease participation. A few days ago I noticed the winter15 logo in the top.
Now there is a significant issue for a staging use case: you can't install managed packages created on summer14 - which is urgently required for the UAT.
So my questions are:
- Is there any documentation which sandbox-pods are prerelease and which are not?
- how can it happen that a sandbox has spun on the prerelease org without being requested as such?
- how to undo this for the current sandbox, with minimal effort? Moving from pod to pod will still be a couple of hours work wasted doing it via the usual deployment and ETL-process run.
- I know that salesforce is able to move orgs on their end from pod to pod in case an appropriate business justification is provided, but I hardly doubt it will work between pods of different releases, right? So in best case it would work earliest in three weeks? (oct 17 for cs17 vs cs18 which would be way too late)
- how can I prevent future sandboxes from spinning unrequested on prerelease pods?
- where exactly is the switch which dictates new sandboxes of being standard or prerelease?
- did anyone of you had an issue like this before and how did you solve it?
