I am looking for other experiences with migration from Classic to Modern folders especially for on premise Orchestrator environments. What is the deciding factor/s to migration from Classic to Modern folders? What were your challenges?
In our situation, we are concerned about not being able to migrate all of the queue transactions over to new queues. Per instructed, only “new” status transactions will be migrated.
In your opinion, what is the major advantage of Modern folders? Are there any issues or headaches with the migration or working with Modern folders? If the big advantage is categorizing your RPA processes, then what is your suggestion for laying out the folders? Organizational structure? Functional? Thank you in advance for your response.
Following. We were a pre-modern on-prem Orchestrator environment, and have now upgraded - so it’s a mishmash we have to straighten out.
As in mishmash, what do you mean? How to lay out the new Modern? What RPAs can move to the modern? What RPAs need more research before moving? ie queue data left behind?
Thank you for responding!
We had things in classic folders that are still in classic folders, but now have things in modern folders too. Mishmash resulting from the upgrade. I don’t know the answers to your questions. That’s why I’m following this post, I have the same questions.
Great! I hope this thread get’s some feedback that will benefit you.
Migrating to Modern, we will be challenged with our queue data i.e. cannot migrate all queue data to modern folders. Therefore, our bots will think certain transactions because the bots from the Modern folder cannot see the Classic folder queue. Boom! Duplicate transaction. We have an open question with UIPATH technical experts whether or not we can “link” classic and modern folders so that our bots can see both classic and modern queues.
Beyond this, it is a matter of understanding the characteristics and how much benefit it offers. Mostly, modern folders seems to provide more flexibility i.e. subfolders and the modern folders pretty much robot independent instead of one robot per folder. Stay tuned!
Tedious, but you could export what’s in the existing queue then import it into the new queue.
We would use Orchestrator Manager tool. You would only be able to migrate queue transactions in the “new” status. UIPATH hasn’t offered and I haven’t read anywhere where I can export and import everything in the queues. This is why we are seeing if it is possible linking Classic to Modern folders; therefore, no migration of transactions.
Export/Import is built in.
When viewing the items in a queue, click this icon
Upload is in the “3 dots” menu
The issue is that the downloaded file isn’t the right format to upload. You have to extract just the SpecificContent column from the downloaded spreadsheet then modify it from JSON to columns before you can import. It’s tedious, but it can be done. After once or twice you get quicker at it.
Thank you. I will review this further.
This is something I am just starting to look at myself and what I am looking at is
Potential options include
- Manipulating the database records (This most likely is NOT supported by UiPath)
- Manual Steps via using Web UI, one entity at a time
- Create script [PowerShell?] to move entity types in bulk
- Orchestrator Manager - Published by UiPath Orchestrator Manager - RPA Component | UiPath Marketplace Has some basic functionality, may not cover all use cases.
The biggest challenge for me with the number of Processes, Assets, etc. is User/Robot Asset Credentials due to the following and not so much of a challenge but an annoyance that I’ll have to recreate these credentials / set their value. If you aren’t into your own scripting, I’d probably look at the Orchestrator Manager as it has a configuration property to tell it to create those credentials with a single space value so at least you have a placeholder for the Asset / User.
- REST API will not provide the credential value
- Fetching of Global Asset Credential Values must be done by a Robot that has access to Folder the asset is in.
- User/Robot specific Credentials can only be fetched by that User/Robot.
Orchestrator Manager does most of its work via API, but in the case of Asset Credentials, it can be configured to use the Robot running the job to fetch the Credential values, but you still have the challenge of User/Robot specific Credentials.
Regarding Processes:
In order for Processes to support all the features of Modern Folders they must use UiPath.System.Activities 19.10.1 or higher.
I’m personally less concerned about the queue items, they are easily fetched via API, Database, Export of WebUI, Workflow, etc. Most likely will have the Classic Entities complete processing of any existing items in the Classic Folder and all new work will be pushed to the Modern Folder.
We don’t need the historical queue items once they have been processed in any capacity. We do general maintenance daily that deleted various records from the database including Queue Items after they are a certain age in order to keep the Database size in check. Any historical reporting is done outside of Orchestrator using something like Splunk, Snowflake, Insights, etc.
The Orchestrator Manager Manual.pdf provided in the Orchestrator Manager download has a good overview of handling the Migration from Classic to Modern Folders and also a couple different structures that can be used.
However you do the migration, you’ll want to double check a couple things
- Deployed packages that use UiPath.System.Activities 19.10.1 or higher (Not a hard requirement)
- For each unattended Robot in a Classic Folder, an equivalent User should be created referencing the same username along with appropriate permissions are provided to the new user.
^^ Probably isn’t something I’ll continue to look at over the next couple weeks, but is on my roadmap to sort out in January as Classic Folders are deprecated with a scheduled deprecation date of Oct 2022, and I’d like to get it out of the way before we upgrade from 2020.10 to 2021.10 as well I am already in the process of migrating Robot and Asset credentials from Orchestrator to an External Credential Provider, so I’d rather only do it once 
Much appreciated. Thank you for your feedback.
Hello,
We’re planning to migrate from On-Prem Orc to Cloud, first testing out a classic folder scenario and subsequently migrating the modern folders.
I’ve read the documentation, watches a few videos, and at the moment I’m wondering how did everyone go around the concept of Environments from the classic folders which does not exist in the Modern folders?
My original thought was to have one tenant for a department, with three parent folders for Dev/UAT/Prod. Since the robots are at the tenant level, with no way of grouping them, would I need to create subfolders for every environment I had in the classic folder?
e.g. I need environment A and environment B. My scenario is that certain processes have to run on certain machines that have the required software, e.g. Process A can only run on machine A, process B can be ran on machine A and B, but I need to make a distinction so Process A does not run on the machine B. Do I achieve this by creating subfolders? e.g UAT parent folder + 2 subfolder for environments?
Thank you.
tl;dr of it is, it can be complicated and really depends on what makes sense to you and how you want to manage it. No one size fits all, but also no wrong way to go about it. Just be sure to take the time to plan it out, factor into how things might change overtime and hopefully that leaves you with something that is easy to manage (Time and Effort) and not something you’ll have to keep coming back to to revamp with each organizational change.
This is entirely up to you and how you want to organize your resources. If you need segregation between departments or ‘environments’ you can use Tenants to do so, but then you are also segregating your licenses (Whether that is a License applied at the Host Level and allocated to the tenants, or if you are applying specific licenses at the tenant level).
You might want to organize using Folders and Sub-Folders perhaps based on organizational department or team structure, or perhaps logical environments Dev/UAT/Prod as you suggest.
The big thing about Modern Folders compared to Classic is you have a lot more flexibility on how to better utilize your available resources (machines/Robots), Access Controls, and sharing resources (Assets, Queues, etc.) between Folders and Users.
In a Classic world, Environments I think get overloaded, and should be more about what combination of Access/Permissions (Robots/Users) and Capabilities/Functions (Machines / OS Profiles) can be grouped together. For example if you have a sub-set of Credentials that can only access resource A, or only have a sub-set of Machines/Profiles with available software, that would have been an “Environment”.
Modern Folders separates the concept of “Robot” into Credentials/User and Machine so each can be allocated independently of each other on 0 or more Modern Folders which gives you the granularity to control which Users can run which Jobs and which Jobs/Process can run on which Machines. If there is no reason to separate them among the already mentioned reasons, but also Security and Privacy Controls, it gives you more access to distribute your available resources across the board and run specific jobs based on their priorities and load.
The other benefit of Modern over Classic is the number of Object you need to define, in Classic if you wanted 100 Robots available, perhaps overlapping in their Credentials, you’d still have to define 100 Objects. In Modern you can define 10 Credentials and 10 Machines and the combination gives you 100 ‘robots’ assuming you have the runtime licenses available.
Modern Folders you can
- Publish Process to the Tenant or Folder Feed
- Share/Link Resource Objects between Folders (Assets, Queues, etc.)
- Define what Users/Groups/Credentials/Machines are available to a Folder (Sub-Folders inherit Users/Groups from Parent(s))
I started with UiPath 2018 (Classic Folders called Organizational Units back then) and am currently on 2020. Originally we had two Orchestrators (Production and Non-Production). Production had a single “Default” Folder while Non-Production has “Default” and “QA” Folder. Default on the Non-Prod is where our developers would do their thing, and QA was intended for QA Testing, but also Change Control Implementation testing. Processes would connect to other systems in their respective environments where available. Overtime due to lack of environment party of remote systems in some cases, we introduced a “UAT” Folder in Production for facilitating limited Testing against Production resources when Test Data, Mocking, or Environment wasn’t generally available.
For QA, UAT, Prod we then also have Environments per Organization Department which quickly became unmanageable due to re-orgs within the company and resource availability (namely licenses). When I reviewed how resources were being used and the differences between them paired with the Machine images we were maintaining and segregation of VLANs, we were able to consolidate down to two environments “Default” and “SpecilizedWhatever” as there was only 2 Processes that needed uniqueue software and Network/Resource Access the others used common configuration of Users/Software/OS Profile.
Around the same time, we also moved to overlapping some of our domain credentials, each folder had at least 2 machines to act as a (Side A & Side B) and the Credential/Machine combination we had say 10 Credentials defined twice (once per machine) to allow balancing for OS/Machine maintenance, ect without taking everything offline or throwing Orchestrator Cluster into maintenance.
Although I started looking at migrating last year, I haven’t started myself due to project re-prioritizations, My current thinking is
- We will still have 2 separate Orchestrators (Actually have a couple sandboxes for testing infrastructure changes on)
Non-Production
- Developers will continue to develop on our Non-production, but move their Work In Progress to their Personal Workspaces Folder
- Default Folder on Non-Prod will exist for Developers testing their work on an Unattended Robot before passing over to QA
- QA Folder on Non-Prod will still exist for QA Testing and Release Implementation Testing
Production
- A couple parent level folders to act as “Global” Folders for Assets, Queues Process, etc. that are shared resources. This could be for Linked/Shared resource or items that are specific to Operations.
- Parent Level Folders perhaps on overarching departments (Customer Care, Operations, etc.) with Sub-Folders as need per Team or Functional Role
- Likely maintain our UAT Folder due to lack of parity between remote systems
The main benefit to this is we can then start to really define our RBAC based on Roles/Capabilities of our End Users and give them more granular control over their Processes and associated Resources. Currently we don’t allow many end users to access the Orchestrator as with Classic Folders this means granting them more access to unrelated resources increasing risk unless we want to needlessly get overcomplicated in our Resource Management.
I don’t think Modern Folders is really going to change how we organize ourselves, but it gives more flexibility to be more granular in Access Controls while lowering the inherit risk of humans all while allowing us to better utilize our existing licensing without over-subscribing.
I’ll also mention that if you are part of UiPath’s Insider program they are currently in a Registration phase for a new Preview “Orchestrator Classic to Modern folder migration guided tool” that is planned to start mid-August and run until abt. the end of October.
Preview Overview
The Orchestrator Product Team is excited to invite you to join our Preview of the Orchestrator Classic to Modern folder migration guided tool which will help map your classic structure to a modern setup and automatically migrate your Orchestrator entities, allowing you to:
- Map Classic Attended Robots to Orchestrator users
- Map Classic Unattended Robots to Robot accounts
- Automatically create modern folder structures and their entities such as: queues, assets, storage buckets, triggers, and processes
Classic folders will phase out in the upcoming 2023.4 release. Removals and deprecation timeline are available here.
Pre-requisites for this Private Preview
Customers must have a non-production Cloud organization with classic folders to evaluate the migration tool.
wow, thank you so much for the insider link and such a detailed response. It has definitely given me food for thought!
ashokkarale
Anil_G
Yoichi
yangyq10
postwick
chandreshsinh.jadeja
aravindbalineni123
Parvathy
aya
PRASHANT_GABHANE