RPA Deploying Bots to Production

Production deployment is the process of moving a fully tested and approved bot from the test environment into the live business environment where it will run on real data and interact with real systems. A structured deployment process minimises the risk of disruption to business operations and ensures the bot runs reliably from day one.

Pre-Deployment Checklist

Before any bot touches production, verify every item on this checklist:

 PEOPLE:
 □ UAT signed off by business process owner
 □ IT security review completed and approved
 □ Go-live date communicated to all stakeholders
 □ Hypercare support team identified and available

 TECHNICAL:
 □ Production Orchestrator configured
 □ Bot machine (VM) provisioned and tested
 □ Bot package published to production Orchestrator feed
 □ All Orchestrator Assets created with production values
 □ Credentials stored in production Credential Store
 □ Schedules created and verified
 □ Queue(s) created in production Orchestrator
 □ Logging configured and tested (logs appear in Orchestrator)
 □ Alert recipients configured (email/SMS on failure)
 □ Firewall rules and network access confirmed for bot machine

 PROCESS:
 □ Business team knows the bot is going live and when
 □ Manual process backup plan documented (if bot fails)
 □ Rollback plan documented (how to revert if critical issue)
 □ Hypercare monitoring schedule defined (first 2 weeks)

Deployment Environments

Professional RPA programmes maintain separate environments to protect production from development and testing activities.

Environment Pipeline

 DEVELOPMENT (DEV)
 ─────────────────────────────────────────────────────
 Where: Developer's machine or dev VM
 Purpose: Build and unit test the bot
 Data: Synthetic test data only
 Access: Development team only
         │
         ▼
 TESTING / QA
 ─────────────────────────────────────────────────────
 Where: Dedicated QA server
 Purpose: Integration and end-to-end testing
 Data: Masked copies of real data
 Access: QA team + development team
         │
         ▼
 USER ACCEPTANCE TESTING (UAT)
 ─────────────────────────────────────────────────────
 Where: Environment mirroring production
 Purpose: Business validation testing
 Data: Real data (masked sensitive fields)
 Access: Business users + BA + developer
         │
         ▼
 PRODUCTION (PROD)
 ─────────────────────────────────────────────────────
 Where: Production server or production cloud
 Purpose: Live bot running on real business data
 Data: Real, unmasked production data
 Access: Strictly controlled — operations team only

Publishing a Bot Package to Orchestrator

Step 1: Publish from UiPath Studio

 In UiPath Studio:
 Design Tab → Publish
 ├── Package Name: InvoiceProcessingBot
 ├── Version: 1.0.0
 ├── Publish Location: Orchestrator (Production Tenant)
 └── Click: Publish

 Result: A NuGet package (.nupkg) is uploaded to Orchestrator.
 Package appears under: Orchestrator → Packages → InvoiceProcessingBot 1.0.0

Step 2: Create a Process in Orchestrator

 Orchestrator → Processes → Add Process
 ├── Name: InvoiceProcessingBot_Prod
 ├── Package: InvoiceProcessingBot 1.0.0
 ├── Environment: Production
 └── Description: Processes AP invoices from inbox 3x daily

 Save → Process is now available to assign to robots.

Step 3: Configure Triggers / Schedule

 Orchestrator → Triggers → Add Trigger
 ├── Process: InvoiceProcessingBot_Prod
 ├── Robot: Production Robot Pool
 ├── Type: Recurring
 ├── Cron Expression: 0 0 9,13,17 * * MON-FRI
 │   (Runs at 9 AM, 1 PM, 5 PM Monday to Friday)
 └── Timezone: Asia/Kolkata

 Save → Bot will now trigger automatically on schedule.

The Go-Live Moment

On the first production run, the deployment team should actively monitor:

• The Orchestrator Jobs dashboard — is the bot running and progressing?
• The live log stream — are activities completing without errors?
• The target application — are records being created correctly?
• The output files or queues — is the bot producing correct results?

Have the developer on standby to respond immediately if any issues arise.

Version Management

Each time the bot is updated, publish a new version number. Orchestrator stores all published versions so you can roll back instantly to any previous version if a new release causes problems.

Rollback Plan

Always document and test the rollback plan before go-live. If the new version fails in production:

 ROLLBACK PROCEDURE:
 1. Stop the current failing job in Orchestrator
 2. Go to Processes → Edit the process
 3. Change the package version to the last known-good version
 4. Save → Re-trigger the process
 5. Verify the previous version is running correctly
 6. Notify stakeholders that rollback is in effect
 7. Investigate root cause of the new version's failure

Hypercare Period

Hypercare is an intensive monitoring period immediately after go-live — typically two weeks. During hypercare:

• The developer monitors every bot run actively
• Response time for issues is 30 minutes or less
• Business users provide daily feedback on bot outputs
• Any issues are fixed in the same day where possible
• Exception rates, processing speed, and accuracy are measured daily

After hypercare, the bot transitions to standard operations monitoring with normal SLA response times.

Post-Deployment Communication

Send a go-live announcement to all relevant stakeholders:

• The bot is now live and running
• What the bot does and when it runs
• Who to contact if they notice an issue
• How to view bot results (Excel report, Orchestrator dashboard, email summary)
• What the business team should still do manually during hypercare monitoring

Summary

Production deployment is a structured process that protects live systems and business data. It begins with a formal pre-deployment checklist covering people, technical, and process readiness. Bots move through Development, QA, UAT, and Production environments. Publishing creates a versioned package in Orchestrator. Schedules automate the trigger. Active monitoring during go-live catches early issues. Version management enables instant rollback. A two-week hypercare period ensures any post-deployment issues are resolved rapidly. A clean deployment builds confidence in the RPA programme and sets the stage for scaling automation across the organisation.