Private corporate batches, live online cohorts and 1-on-1 mentoring in operating a legacy Atlassian Stash instance and upgrading it to Bitbucket Data Center or migrating to Bitbucket Cloud — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Stash for what it now is — an inherited Git server that has to be understood, upgraded and eventually retired. Sessions cover the instance itself first: the home directory and configuration files, external database and JVM settings, reverse proxy and base URL, backup with the Atlassian backup client and a rehearsed restore. Then the governance surface that has to survive any move — the project, repository and branch permission hierarchy, default reviewers and merge checks, and pre-receive hooks that enforce policy server-side. Finally the migration engineering: the supported version chain from Stash through Bitbucket Server to Data Center, add-on and application-link compatibility, the Bitbucket Cloud migration route with its fidelity limits, and how to leave a read-only archive behind rather than carrying everything forward.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Stash that means a trainer who has run it in production — operating a legacy Atlassian Stash instance and upgrading it to Bitbucket Data Center or migrating to Bitbucket Cloud — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Stash batchStash is the original name of Atlassian's self-hosted Git repository server. Atlassian renamed it Bitbucket Server in 2015, and later folded it into Bitbucket Data Center; the Server edition itself reached end of support in February 2024. So if you are looking for Stash training, you are almost certainly looking at one of two situations: an instance still running under the old name and the old version, or a team whose documentation, scripts and internal wiki still say Stash while the software underneath has moved on. This page is written for both, and it will not pretend Stash is a current product.
Underneath the naming, the model has been stable for a decade. Repositories live inside projects; permissions cascade from global to project to repository and are then narrowed by branch permissions; pull requests carry default reviewers and merge checks; and pre-receive and post-receive hooks enforce policy on the server rather than trusting client-side convention. The instance is a Java application with a home directory, an external database, a base URL behind a reverse proxy, and a licence tied to user tier — which is exactly the surface an administrator has to know to upgrade it.
What has changed is everything around it. Add-ons that worked on Stash 3.x may not exist for current Bitbucket. The supported upgrade path is a chain of version hops with database and Java requirements at each step, not a single jump. Application links to Jira, Bamboo, Fisheye and Crucible need re-establishing. And the destination is a real choice: stay self-hosted on Bitbucket Data Center, move to Bitbucket Cloud, or leave Atlassian for another Git host.
An unsupported source control server is not a neutral risk. It is where every line of your source code lives, it authenticates against your directory, it holds credentials for your CI system, and it stops receiving security fixes the moment support ends. Bitbucket Server passed that point in February 2024, and Stash-era versions passed it many years earlier.
The reason these instances survive is rarely negligence. It is that the upgrade path is genuinely non-trivial — multiple version hops, database and Java changes, add-on compatibility gaps, application links to re-establish, and hooks or scripts written against an old API — and nobody has been given the time to do it properly. So the server sits there, patched around, until an audit finding or a hardware failure forces the issue.
The skill worth training is therefore narrow and practical: read the instance you have, plan a supported upgrade chain, rehearse it against a restored copy, decide honestly which repositories deserve migration and which should become a read-only archive, and know what a move to Bitbucket Cloud or another host does and does not carry with it. Done deliberately this is a scheduled project with a rollback. Done reactively it is an incident.
Start by naming the thing correctly, because every piece of documentation depends on it. The renaming history and version map, how to determine the exact version, edition and licence tier of a live instance, and what each generation supports. Then the object model that has stayed constant throughout — projects, repositories, permissions, pull requests and hooks — so the rest of the course has one vocabulary.
Topics: Naming and version history: Stash, Bitbucket Server, Bitbucket Data Center · Determining version, edition, licence tier and user count on a live instance · Support status and what an unsupported server means in practice · Projects, repositories and the object model · Permission hierarchy overview · Where Bitbucket Cloud differs from the self-hosted product
The administrative floor. The home directory and what lives in it, the configuration files that control behaviour, external database configuration and connection pooling, JVM and memory sizing, base URL and reverse proxy with SSL termination, and the diagnostic surface: log locations, support zips and the symptoms that point at the database rather than the application.
Topics: Home directory layout and what must be backed up with it · Configuration files and property precedence · External database configuration and connection pooling · JVM sizing, garbage collection and memory symptoms · Reverse proxy, base URL and SSL termination · Logs, support zips and diagnosing a slow instance · Repository size, garbage collection and disk growth
The module that decides whether the rest of the plan is possible, because every upgrade rehearsal starts from a restore. Backup strategy for the home directory and database together, the Atlassian backup client and zero-downtime approaches, restoring into a clean environment, and rehearsing the failure you are actually exposed to rather than the one that is easy to test.
Topics: What must be backed up: home directory, database and their consistency · The Atlassian backup client and zero-downtime backup options · Restore into a clean environment and verifying integrity · Verifying repositories, pull requests, permissions and hooks survived · Disaster recovery planning and recovery point objectives · Using a restored copy as the upgrade rehearsal environment
The governance that has to survive whatever you migrate to, so it is worth understanding before the move rather than rebuilding blind afterwards. The permission hierarchy from global to project to repository, branch permissions and write restrictions, user and group management with directory integration, and server-side hooks — the only mechanism that enforces policy rather than requesting it.
Topics: Global, project and repository permission levels · Branch permissions, write restrictions and preventing force push · Users, groups and LDAP or Active Directory integration · Service accounts, SSH keys and access tokens · Pre-receive hooks and enforced policy · Post-receive hooks and downstream notification · Auditing effective permissions for a user
The review process as a control rather than a courtesy. Pull request lifecycle, default reviewers and reviewer groups, merge checks including minimum approvals, resolved tasks and required successful builds, merge strategies, and the notification configuration that determines whether reviews are seen. Then the practical question of reducing review latency without weakening the gate.
Topics: Pull request lifecycle and review mechanics · Default reviewers and reviewer groups · Merge checks: minimum approvals, resolved tasks, required builds · Merge strategies and their history consequences · Tasks, comment threads and review conventions · Notification and email configuration · Measuring and reducing review latency
Everything connected to the instance is a migration constraint, so it gets inventoried and understood here. Application links to Jira, Bamboo, Fisheye and Crucible, smart commits, webhooks and their older POST-hook ancestors, the REST API and the scripts written against it, and Marketplace add-ons — including which are abandoned and which have a supported successor.
Topics: Application links to Jira, Bamboo, Fisheye and Crucible · Jira issue linking and smart commits · Webhooks, legacy POST hooks and their consumers · The REST API and scripted administration · Jenkins and external CI integration patterns · Marketplace add-ons: inventory, compatibility and abandonment · Identifying every script and system that would break on a move
Getting from an old version to a supported one, which is a chain rather than a jump. Working out the supported hops, the database and Java requirements at each, add-on compatibility gaps, licence and edition changes, and the rehearsal discipline: run the whole chain against a restored copy, record every error, then repeat it in production against a clock with a rollback available.
Topics: Determining the supported upgrade chain from your version · Database and Java requirements at each hop · Add-on compatibility and finding replacements · Licence, edition and user-tier changes on the way to Data Center · Rehearsing the full chain against a restored copy · Data Center concepts: clustering, shared home and smart mirroring · Production run: freeze window, timings, verification and rollback
The alternative destination, treated honestly. Atlassian's Cloud migration tooling and what it carries — repositories, pull requests, permissions, users — against what it does not. Identity mapping to a cloud directory, the add-ons and hooks that have no cloud equivalent, and the same exercise for a move to GitHub or GitLab. Then the decision most projects underestimate: what to migrate versus what to leave as a read-only archive.
Topics: Bitbucket Cloud migration tooling and its scope · What migrates: repositories, pull requests, permissions, users · What does not: hooks, add-ons, some history metadata and integrations · Identity mapping and directory alignment · Migration to GitHub or GitLab as an alternative destination · Deciding what to migrate, archive or delete · Cutover: freeze, remote redirection, verification and rollback · Standing up a read-only archive for audit and retention
We rebuild the agenda around the tools you actually run.
Request a custom agendaDetermine version, edition, database, Java, licence tier, add-ons and every external integration on an unfamiliar instance, using the admin console, logs and the REST API.
Take a consistent home-directory and database backup, destroy the instance, restore it into a clean environment and verify repositories, pull requests and permissions survived.
Build a permission model across project, repository and branch levels, add a pre-receive hook, then attempt to force-push and merge without approval from a normal account.
Run the first hops of a real upgrade chain against a restored copy, recording database and Java requirements, add-on breakage and elapsed time for each step.
Move a sample project to a destination host, then systematically list what did not carry across — hooks, add-ons, permissions, metadata — and decide what to rebuild.
Plan and rehearse a full cutover with a freeze window, verification checklist, rollback trigger and a read-only archive that satisfies retention without being carried forward.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.