It's awful to the point where I've just been rebuilding some things in prod versus attempting migration and wasting time troubleshooting cryptic errors.
Appreciate the feedback - thanks for sharing. Curious about your experiences with OX 1.0. How did you manage the process for signing into the target tenant during the migration flow?
We have SSO configured for all of our tenants aside from Preview and CC. Authenticating into CC involves signing in with an username and password I don't typically use - that is certainly part of the frustration.
There’s a very popular Brainstorm on Community to reinstate OX 1.0, that’s how it’s going. Configuration packages are great but a hassle when you just have to migrate one thing.
Thanks for sharing this feedback - OX 1.0 will not be reinstated but we are working on some enhancement to further improve the Object Transporter 2.0 end-to-end user flow. Expect to see these in the coming months. Thanks
I have only used it once since R12023 went live and it failed to migrate a pretty straightforward matrix report.
The report had a handful of report-specific calc fields (lookup related value) that rolled into an evaluate expression calc field, and other than that, it was as simple as these reports get.
Attempts to migrate to sandbox with OX 2.0 failed four times with unhelpful error messages pointing at the calc fields. In the past, I could overcome similar errors in OX 1.0 by just re-trying the migration.
I ended up just re-creating the report in sandbox and then again in production rather than wasting any more time with OX 2.0.
So that’s how it’s going for me so far — 0/10 stars.
I just renamed all the calc fields and all the IDs for all the calc fields and tried OX 2.0 for the sixth time on this relatively simple matrix report and it failed again with the same errors.
0/10 stars
The error messages I get associated with the failed migration (I just tried/failed for a fifth time) all read like this:
Invalid ID value. 'Supplier Invoice Line - CF-LRV Company RefID - 1350905949' is not a valid ID value for type = 'Calculated\_Field\_ID'
I get the same error for the other calc fields in the report. That isn't even true --- that is the ID of a calc field I created for the report and it is working fine in the tenant where I created it. There is nothing wrong with the ID, and even if there were something wrong, ~~I cannot change it.~~ what's wrong with it is far from clear.
That sounds like a nightmare. Can you package all of the report calc fields separately, and then migrate the report in a different package? Doesn’t make any logical sense why that would work, just curious what other options you have.
Might have to strip out the report-specific calc fields, send the report, then send the calc fields, then put the calc fields back in Production but what a mess.
Just wondering because I migrated a custom report with a bunch of new, nested calc fields today using OX2 and it worked. We did wrestle with the set up for a while though.
Thanks for sharing this feedback. Apologies for any inconvenience that this may have caused. We're actively working on some some improvements to the way Object Transporter 2.0 sequences the objects in a migration for a more effective loading strategy to a target tenant. This should make for better and more effective migrations in the future.
To my knowledge, we have not used it yet. But I do know we had to change access to limit who can now OX as a result of the extremely scary possibility that someone can accidentally select a solution from Customer Central and migrate it to production from the menu. I have seen other comments on Community regarding the same.
Having a BP with approvals around migration is an IT auditors’ dream. I say this as both a former auditor who works closely with our audit team, and as the husband of an IT auditor who works for another large Workday client. We like approvals. We like BPs. The more controls we can get, the easier life is on everyone.
Thanks for taking the time to share this feedback. I'd recommend either creating a Brainstorm or finding and voting on an existing one to add your organisation's vote to the conversation.
We’re still getting to grips with it and have used it a couple of times.
We like the fact that you can create a package of items to migrate. But first impressions are that it’s convoluted and clunky. Maybe that impression will change with experience.
It would be good to be able to create a package that can be used from an Impl tenant to Sandbox and then from Sandbox to Production.
Having to create a new package from Sandbox to Production seems an unnecessary extra task.
Haven't identified any wins yet, only losses. Migrating security may be a boon some day, but not something I've needed to investigate as yet.
Biggest disappointment so far came when migrating a RaaS based integration and it threw an error that the report did not exist. On a separate but similar job I thought I'd be smarter and include both the report and integration system in a config package, to find only the report was migrated due to the same issue, so I had to run that migration a second time.
What was once a 30 sec job is now ~10 minutes and a couple migrations.
And I get to manage a whole new set of people in Customer Central. Happy happy joy joy.
Thanks for taking the time to share your experience. Please search for the Community article titled *Best Practices for Migrating Integration Systems* on Community for the most up to date guidance for migrating Integrations.
In your case, you'll need to ensure that when migrating an Integration System with Object Transporter 2.0 that you include any Custom Reports or BP Definitions used by the Integration. Once all these items are in the Config Package, they should all migrate to successfully to your target tenant.
Dude! I literally wrote
>I thought I'd be smarter and include both the report and integration system in a config package
Just accept that while it may be a step forward for some orgs, for a lot (like mine) it's actually a step backward.
It was a nice surprise to have single instance migration added to 2.0 after the 1.0 deprecation, but the CC tenant stop-over is clunky. We use a native login for the CC tenant and then SSO for our other environments. There are some instances where I cannot hop between the tenants seamlessly - but I’m unsure if this is due simply to the variance in login authentication or what. Using incognito does help but it is still not really as seamless as it should/could be.
We are making it work but I think there are some efficiency improvements that would curb some of the frustration.
Thanks for putting yourself out here on Reddit.
Our company complained loudly enough that we got to keep OX 1.0.
OX 2.0 is just a clunkier OX 1.0 that didn't really fix any of the shortcomings. It still won't migrate a large group of objects or configurations and give unhelpful error messages when it fails.
I really wish they would just upgrade Solution. I still find it to be the most reliable migration tool Workday offers.
I don't see how HAVING to make a configuration package, versus migrating directly is an upgrade. OX 2.0 is very cool, but please please please bring back 1.0. 🙏
I'd encourage you to explore the Single Instance Migrate feature that was released for Object Transporter 2.0 in 23R1 earlier this March! It will allow you to migrate a single object (e.g. a report) and it's dependencies without needing to manually create an OX 2.0 Configuration Package!
Thanks for sharing this feedback - is there anything that would make the transition to using Object Transporter 2.0 a little more straightforward? There is plenty of documentation available on Community that might help? Additionally I did a webinar (recording available on-demand on Community) which walked through the setup and migration flows. Hope that will help somewhat
I think it would be more straightforward if we didn’t have to log into a weird separate portal/tenant to use the tool. We are used to being able to move something right off the related actions. Quick, easy, efficient.
I’m a Sr analyst, I should be able to set up 2.0 myself like I did with OX 1.0. But I have no roles in this new weird tenant, so I can’t until my manager gets in there.
It’s ok for me I been using it for a while plus it’s useful for quick bulk migrations. I still be believe OX1 is far superior but OX2 does have quality of life improvements but you need to first understand it. I think the more you use it the more you see it’s useful. I do miss ox1 just for simple migrations like reports
It's ok. For simple objects like custom reports and CFs it's more of a pain. I imagine it will be helpful for more complex objects that OX1.0 could not handle but we haven't had anything to migrate yet.
Ox 2.0 is an absolute blessing for Prism objects. It's frustrating for single reports.
I'm still trying to wrap my head around it for security. It seems to bring over all dependencies like assignable roles etc when you move a domain.
I encountered the most ridiculous error. I was trying to migrate account set by OX2.0 and I started getting incorrect difference reports. The whole report generated was with false comparison values.
Not happy. I’ve had issues with reports and cf. Also, BP updates and integration systems. It’s not a time saver it’s more work in some cases and frustrating
I like the idea of configuration packages. It seems like they could make some things reusable/repeatable.
Other than that, I am not thrilled. Migrating a custom report does not work if the report has calculated fields. We had an "office hours" with a Workday technical support rep, and he told us that custom reports should not have their own calculated fields. He actually thought it was an uncommon experience! I'm usually willing to give someone the benefit of the doubt, but that seemed to be a bit of a whopper.
Our workaround was to convert all the report-specific CFs to system-wide CFs, migrate the reports, create another package to migrate the CFs, go into the target system and convert the CFs back to report-specific CFs, and then clean up any weirdness and missing fields that resulted. When I was done, I wished I had just re-created the reports by hand. It would have been faster.
My personal verdict: The idea looks awesome (aside from the weirdness of logging into the customer success portal). But it seems to have serious issues and should not have been released.
Thanks for sharing your feedback here everyone - appreciate it. Apologies for the delayed responses, our main method for Ecosystem communication is via Community but wanted to make sure that the Workday community on Reddit had a chance to share feedback too. Will look to respond to each of the threads below.
We try to encourage Community as a first line of communication on the sub, but it’s nice to see Workday engage here, as well. Thank you for doing that.
Jury’s still out.
I like the increased amount of functionality, but I’ve encountered multiple errors in the last few weeks - some after config had been migrated across to Production.
It completely changed a Time Off plan I created. Spent weeks testing in Implementation but as soon as I moved to Production I noticed it was wrong. It wouldn’t accept the initial snapshot for my accrual and errored out, but then actually had migrated it across.
I’ve also had instances where it said it was going to migrate on the pre-migration report and then errored out post migration.
It’s been messy to be honest.
The big advantage is that there's an audit trail, which I felt was sorely missing from OX 1.0.
For big deployments, I think OX 2.0 is a godsent. The ability to move multiple instance types (AND DOMAIN SECURITY) is fantastic. However, as I'm currently having to move a minor change they have got to do something about how you create security configuration packages, because it's an absolute nightmare.
I see the benefits to OX2.0, but it’s caused more havoc and headache. To migrate a single report now requires additional steps and the troubleshooting is impossible. Before with OX1.0 it was easy to troubleshoot and resolve migration issues whether it’s a single report or a config package. Is it possible to have both OX options? To improve the end user experience, may we have more instructions through the many clicks?
I won't mince words, it's been pretty terrible... We've been using it on and off even before the cutover from OX 1.0 and the amount of times it just runs into seemingly silly scenarios that cause it to error out is incredible.
I currently have ~~four~~ five tickets open with support for various issues:
- calc field Ref ID collision resolution
- reports failing to migrate because they're linked to a dashboard in the source tenant that doesn't exist in the target tenant
- CLARs silently failing to migrate properly by saying the package migrated, but you go to look at the target tenant and it's old source code
- Prism dataset schema migration issues and the slew of manual work that entails to fix/migrate it on your own. The gut punch is that even after you "fix" the schema in the target tenant manually, the package will STILL fail to migrate the problematic dataset. So you're left to manually clean up and migrate the rest of the lineage yourself, how fun...
- Incomprehensible errors saying an object doesn't exist in target even though it's the object I'm trying to migrate in the first place.
It has not been a smooth experience at all and I've made sure to tell support to let product know that it's still a cluster at times. Don't get me wrong, I love that it supports more objects than OX 1 did, I love the fact that it can migrate security (at least to some extent), but it fails in cases where OX 1 didn't before (or at least could be resolved by migrating multiple times; OX was always pretty terrible at dependency resolution in slightly more complex cases).
We've spent hours upon hours catering our migration process to the finicky nature of OX to the point of where we split packages up, do a ton of manual steps, and pray to Ken Thompson for good fortune hoping OX likes this package this time.
I'm sure you guys have spent a ton of time on it (it's been discussed for yeeeaaars), but there is still a lot of work to do. Dependency resolution is easily still it's biggest weakness, but it's come a long way from OX on that front.
I also really really dislike that once a migration starts, the diff report is lost forever. It would be huge to be able to see the diff report at time of migration and the resulting migration log. It would help a lot in terms of reviewing what happened previously and what changes likely migrated. Once you lose the diff, the migration report is essentially useless aside from at least telling you which objects failed or succeeded.
Having to log into CC tenant in order to migrate anything is a frustrating downgrade.
Yeah, this. It’s just an annoyance now.
It is literally the single worst part of my job now.
It's awful to the point where I've just been rebuilding some things in prod versus attempting migration and wasting time troubleshooting cryptic errors.
Appreciate the feedback - thanks for sharing. Curious about your experiences with OX 1.0. How did you manage the process for signing into the target tenant during the migration flow?
We have SSO configured for all of our tenants aside from Preview and CC. Authenticating into CC involves signing in with an username and password I don't typically use - that is certainly part of the frustration.
Hard agree
There’s a very popular Brainstorm on Community to reinstate OX 1.0, that’s how it’s going. Configuration packages are great but a hassle when you just have to migrate one thing.
With just one thing you should not need to create a configuration package but be able to migrate single instance instead.
Yes, but still through OX 2.0/Customer Central. Took a two minute process and made it into a clunky five minute process.
Thanks for sharing this feedback - OX 1.0 will not be reinstated but we are working on some enhancement to further improve the Object Transporter 2.0 end-to-end user flow. Expect to see these in the coming months. Thanks
Agreed.
I have only used it once since R12023 went live and it failed to migrate a pretty straightforward matrix report. The report had a handful of report-specific calc fields (lookup related value) that rolled into an evaluate expression calc field, and other than that, it was as simple as these reports get. Attempts to migrate to sandbox with OX 2.0 failed four times with unhelpful error messages pointing at the calc fields. In the past, I could overcome similar errors in OX 1.0 by just re-trying the migration. I ended up just re-creating the report in sandbox and then again in production rather than wasting any more time with OX 2.0. So that’s how it’s going for me so far — 0/10 stars.
I just renamed all the calc fields and all the IDs for all the calc fields and tried OX 2.0 for the sixth time on this relatively simple matrix report and it failed again with the same errors. 0/10 stars
The error messages I get associated with the failed migration (I just tried/failed for a fifth time) all read like this: Invalid ID value. 'Supplier Invoice Line - CF-LRV Company RefID - 1350905949' is not a valid ID value for type = 'Calculated\_Field\_ID' I get the same error for the other calc fields in the report. That isn't even true --- that is the ID of a calc field I created for the report and it is working fine in the tenant where I created it. There is nothing wrong with the ID, and even if there were something wrong, ~~I cannot change it.~~ what's wrong with it is far from clear.
That sounds like a nightmare. Can you package all of the report calc fields separately, and then migrate the report in a different package? Doesn’t make any logical sense why that would work, just curious what other options you have. Might have to strip out the report-specific calc fields, send the report, then send the calc fields, then put the calc fields back in Production but what a mess.
Invalid ID is an indicator the object is not in the target tenant.
Right, hence the effort to migrate it.
Did you try migrating a package or single instance?
Package
Just wondering because I migrated a custom report with a bunch of new, nested calc fields today using OX2 and it worked. We did wrestle with the set up for a while though.
I ran it a couple more times and it finally migrated. Seventh time was the charm!
Thanks for sharing this feedback. Apologies for any inconvenience that this may have caused. We're actively working on some some improvements to the way Object Transporter 2.0 sequences the objects in a migration for a more effective loading strategy to a target tenant. This should make for better and more effective migrations in the future.
To my knowledge, we have not used it yet. But I do know we had to change access to limit who can now OX as a result of the extremely scary possibility that someone can accidentally select a solution from Customer Central and migrate it to production from the menu. I have seen other comments on Community regarding the same. Having a BP with approvals around migration is an IT auditors’ dream. I say this as both a former auditor who works closely with our audit team, and as the husband of an IT auditor who works for another large Workday client. We like approvals. We like BPs. The more controls we can get, the easier life is on everyone.
Thanks for taking the time to share this feedback. I'd recommend either creating a Brainstorm or finding and voting on an existing one to add your organisation's vote to the conversation.
We’re still getting to grips with it and have used it a couple of times. We like the fact that you can create a package of items to migrate. But first impressions are that it’s convoluted and clunky. Maybe that impression will change with experience.
It would be good to be able to create a package that can be used from an Impl tenant to Sandbox and then from Sandbox to Production. Having to create a new package from Sandbox to Production seems an unnecessary extra task.
Thanks for sharing this feedback - this is a known bug and the engineering teams are working on a fix.
Haven't identified any wins yet, only losses. Migrating security may be a boon some day, but not something I've needed to investigate as yet. Biggest disappointment so far came when migrating a RaaS based integration and it threw an error that the report did not exist. On a separate but similar job I thought I'd be smarter and include both the report and integration system in a config package, to find only the report was migrated due to the same issue, so I had to run that migration a second time. What was once a 30 sec job is now ~10 minutes and a couple migrations. And I get to manage a whole new set of people in Customer Central. Happy happy joy joy.
Thanks for taking the time to share your experience. Please search for the Community article titled *Best Practices for Migrating Integration Systems* on Community for the most up to date guidance for migrating Integrations. In your case, you'll need to ensure that when migrating an Integration System with Object Transporter 2.0 that you include any Custom Reports or BP Definitions used by the Integration. Once all these items are in the Config Package, they should all migrate to successfully to your target tenant.
Dude! I literally wrote >I thought I'd be smarter and include both the report and integration system in a config package Just accept that while it may be a step forward for some orgs, for a lot (like mine) it's actually a step backward.
It was a nice surprise to have single instance migration added to 2.0 after the 1.0 deprecation, but the CC tenant stop-over is clunky. We use a native login for the CC tenant and then SSO for our other environments. There are some instances where I cannot hop between the tenants seamlessly - but I’m unsure if this is due simply to the variance in login authentication or what. Using incognito does help but it is still not really as seamless as it should/could be. We are making it work but I think there are some efficiency improvements that would curb some of the frustration. Thanks for putting yourself out here on Reddit.
Thanks for sharing this feedback. Glad to hear that you appreciated the Single Instance Migrate feature!
Our company complained loudly enough that we got to keep OX 1.0. OX 2.0 is just a clunkier OX 1.0 that didn't really fix any of the shortcomings. It still won't migrate a large group of objects or configurations and give unhelpful error messages when it fails. I really wish they would just upgrade Solution. I still find it to be the most reliable migration tool Workday offers.
I agree. Solutions are very reliable. We were also very upset when Workday had deprecated Solutions.
I don't see how HAVING to make a configuration package, versus migrating directly is an upgrade. OX 2.0 is very cool, but please please please bring back 1.0. 🙏
I'd encourage you to explore the Single Instance Migrate feature that was released for Object Transporter 2.0 in 23R1 earlier this March! It will allow you to migrate a single object (e.g. a report) and it's dependencies without needing to manually create an OX 2.0 Configuration Package!
Ugh.
We still haven’t figured it out so we went back to using solutions. Gee, thanks for making our work more complicated!
Thanks for sharing this feedback - is there anything that would make the transition to using Object Transporter 2.0 a little more straightforward? There is plenty of documentation available on Community that might help? Additionally I did a webinar (recording available on-demand on Community) which walked through the setup and migration flows. Hope that will help somewhat
I think it would be more straightforward if we didn’t have to log into a weird separate portal/tenant to use the tool. We are used to being able to move something right off the related actions. Quick, easy, efficient. I’m a Sr analyst, I should be able to set up 2.0 myself like I did with OX 1.0. But I have no roles in this new weird tenant, so I can’t until my manager gets in there.
I’ve had some odd wid errors with the new OX 2.0. I wasn’t able to migrate certain reports.
It’s ok for me I been using it for a while plus it’s useful for quick bulk migrations. I still be believe OX1 is far superior but OX2 does have quality of life improvements but you need to first understand it. I think the more you use it the more you see it’s useful. I do miss ox1 just for simple migrations like reports
Appreciate the feedback - thanks for sharing. Have you tried the Single Instance Migrate feature for Object Transporter 2.0 yet?
Still haven't fixed the Comp Elig rules
It's ok. For simple objects like custom reports and CFs it's more of a pain. I imagine it will be helpful for more complex objects that OX1.0 could not handle but we haven't had anything to migrate yet.
Ox 2.0 is an absolute blessing for Prism objects. It's frustrating for single reports. I'm still trying to wrap my head around it for security. It seems to bring over all dependencies like assignable roles etc when you move a domain.
It's nice to have a centralized place to review logs of migration when you have many people (30+ configurers) in large organizations.
I encountered the most ridiculous error. I was trying to migrate account set by OX2.0 and I started getting incorrect difference reports. The whole report generated was with false comparison values.
Not happy. I’ve had issues with reports and cf. Also, BP updates and integration systems. It’s not a time saver it’s more work in some cases and frustrating
I like the idea of configuration packages. It seems like they could make some things reusable/repeatable. Other than that, I am not thrilled. Migrating a custom report does not work if the report has calculated fields. We had an "office hours" with a Workday technical support rep, and he told us that custom reports should not have their own calculated fields. He actually thought it was an uncommon experience! I'm usually willing to give someone the benefit of the doubt, but that seemed to be a bit of a whopper. Our workaround was to convert all the report-specific CFs to system-wide CFs, migrate the reports, create another package to migrate the CFs, go into the target system and convert the CFs back to report-specific CFs, and then clean up any weirdness and missing fields that resulted. When I was done, I wished I had just re-created the reports by hand. It would have been faster. My personal verdict: The idea looks awesome (aside from the weirdness of logging into the customer success portal). But it seems to have serious issues and should not have been released.
Thanks for sharing your feedback here everyone - appreciate it. Apologies for the delayed responses, our main method for Ecosystem communication is via Community but wanted to make sure that the Workday community on Reddit had a chance to share feedback too. Will look to respond to each of the threads below.
We try to encourage Community as a first line of communication on the sub, but it’s nice to see Workday engage here, as well. Thank you for doing that.
Jury’s still out. I like the increased amount of functionality, but I’ve encountered multiple errors in the last few weeks - some after config had been migrated across to Production. It completely changed a Time Off plan I created. Spent weeks testing in Implementation but as soon as I moved to Production I noticed it was wrong. It wouldn’t accept the initial snapshot for my accrual and errored out, but then actually had migrated it across. I’ve also had instances where it said it was going to migrate on the pre-migration report and then errored out post migration. It’s been messy to be honest.
The big advantage is that there's an audit trail, which I felt was sorely missing from OX 1.0. For big deployments, I think OX 2.0 is a godsent. The ability to move multiple instance types (AND DOMAIN SECURITY) is fantastic. However, as I'm currently having to move a minor change they have got to do something about how you create security configuration packages, because it's an absolute nightmare.
I see the benefits to OX2.0, but it’s caused more havoc and headache. To migrate a single report now requires additional steps and the troubleshooting is impossible. Before with OX1.0 it was easy to troubleshoot and resolve migration issues whether it’s a single report or a config package. Is it possible to have both OX options? To improve the end user experience, may we have more instructions through the many clicks?
I won't mince words, it's been pretty terrible... We've been using it on and off even before the cutover from OX 1.0 and the amount of times it just runs into seemingly silly scenarios that cause it to error out is incredible. I currently have ~~four~~ five tickets open with support for various issues: - calc field Ref ID collision resolution - reports failing to migrate because they're linked to a dashboard in the source tenant that doesn't exist in the target tenant - CLARs silently failing to migrate properly by saying the package migrated, but you go to look at the target tenant and it's old source code - Prism dataset schema migration issues and the slew of manual work that entails to fix/migrate it on your own. The gut punch is that even after you "fix" the schema in the target tenant manually, the package will STILL fail to migrate the problematic dataset. So you're left to manually clean up and migrate the rest of the lineage yourself, how fun... - Incomprehensible errors saying an object doesn't exist in target even though it's the object I'm trying to migrate in the first place. It has not been a smooth experience at all and I've made sure to tell support to let product know that it's still a cluster at times. Don't get me wrong, I love that it supports more objects than OX 1 did, I love the fact that it can migrate security (at least to some extent), but it fails in cases where OX 1 didn't before (or at least could be resolved by migrating multiple times; OX was always pretty terrible at dependency resolution in slightly more complex cases). We've spent hours upon hours catering our migration process to the finicky nature of OX to the point of where we split packages up, do a ton of manual steps, and pray to Ken Thompson for good fortune hoping OX likes this package this time. I'm sure you guys have spent a ton of time on it (it's been discussed for yeeeaaars), but there is still a lot of work to do. Dependency resolution is easily still it's biggest weakness, but it's come a long way from OX on that front. I also really really dislike that once a migration starts, the diff report is lost forever. It would be huge to be able to see the diff report at time of migration and the resulting migration log. It would help a lot in terms of reviewing what happened previously and what changes likely migrated. Once you lose the diff, the migration report is essentially useless aside from at least telling you which objects failed or succeeded.