Private corporate batches, live online cohorts and 1-on-1 mentoring in modernising a legacy TFS estate — TFVC to Git, XAML builds to pipelines, and migration to Azure DevOps Server or Services — 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 TFS modernisation as a migration engineering problem rather than a product tour — auditing what a deployment actually contains before touching it, choosing between in-place upgrade to Azure DevOps Server and migration to Azure DevOps Services, converting TFVC to Git with git-tfs and the import tooling while being explicit about what history and branch topology survive the conversion, and rebuilding XAML builds and classic Release Management templates as agent-based pipelines with approvals and gates. Sessions also cover the unglamorous half: identity mapping, collection detach and attach, consistent backup across configuration and collection databases, and keeping the legacy instance safe and restorable for as long as it has to live.
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 TFS that means a trainer who has run it in production — modernising a legacy TFS estate — TFVC to Git, XAML builds to pipelines, and migration to Azure DevOps Server or Services — 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 TFS batchTFS is the everyday name for Team Foundation Server, Microsoft's on-premises application lifecycle management platform. One server, backed by SQL Server, carries work item tracking, version control in both TFVC and Git, build automation, release management and test management, organised into team project collections that each map to their own database. From the 2019 release Microsoft renamed the product Azure DevOps Server, and the hosted equivalent is Azure DevOps Services — the same lineage under three names, which is why searching for an answer about TFS so often returns documentation for a product that behaves differently.
This page is deliberately narrower than a full Team Foundation Server course. It is for teams who already run a TFS instance and now have two jobs at once: keep it available, restorable and secure while it lasts, and get the work off it. Those are different skills. Operating the instance is administration; moving off it is a migration project with fidelity decisions, identity mapping, history trade-offs and a cutover that has to be rehearsed.
The modernisation work splits into four tracks that can run independently: version control from TFVC to Git, builds from XAML definitions to agent-based YAML pipelines, releases from the classic Release Management templates to multi-stage pipelines with approvals and gates, and reporting from the warehouse-and-cube plus SharePoint model to Analytics and dashboards. Underneath all four sits the platform decision itself — in-place upgrade to Azure DevOps Server, migration to Azure DevOps Services, or a move to a different platform entirely — and the honest answer differs by estate.
Most organisations running TFS are not running it by choice any more. They are running it because a decade of work item history, process customisation, build definitions and audit evidence lives inside it, and nobody has been given the time to move it. Meanwhile the version they are on drifts further from anything Microsoft is documenting, the engineers who configured it have left, and the estate becomes something people are afraid to touch.
That fear is expensive. It stops upgrades, which stops security patching. It pushes teams into shadow tooling, which fragments traceability — exactly the thing TFS was bought to provide. And it turns a migration that could have been planned into one that eventually happens under pressure, when a server fails or an audit finding lands.
The skill in demand is not TFS trivia. It is the ability to audit an estate honestly, decide what migrates and what should be archived read-only rather than carried forward, convert TFVC history into Git without producing an unusable repository, rebuild builds and releases as pipelines that are better than the ones they replace, and run the cutover with a tested rollback. Done properly this is a few months of deliberate work; done badly it is a permanent parallel-running tax.
Nothing gets migrated before it is understood. This module builds an accurate picture of a real TFS deployment: version and update level, topology, how many collections and projects, which process templates and process models, how much source is in TFVC versus Git, which builds are XAML and which are agent-based, whether the warehouse and cube or a SharePoint portal is in use, and which extensions and custom work item types exist.
Topics: Determining version, update level and topology · Collection and team project inventory · Process templates and the XML versus inherited process model · TFVC versus Git usage, repository sizes and history depth · XAML builds, agent-based builds and which are still running · Warehouse, cube, SharePoint portal and reporting dependencies · Custom work item types, check-in policies, plugins and third-party extensions
Three genuinely different destinations, and the constraints that pick between them. In-place upgrade to Azure DevOps Server keeps everything on your hardware and inside your network. Migration to Azure DevOps Services moves to Microsoft's hosted service with the data migration tool. A third option — move to another platform entirely — is right more often than vendors admit. The module works through supported paths, blockers and cost rather than preference.
Topics: Supported upgrade paths and the version hops they require · Hardware, SQL Server and Windows requirements for a modern release · Dry-run upgrade against a restored copy before touching production · Azure DevOps Services migration: the data migration tool and its prerequisites · Size limits, unsupported features and what the migration tool refuses · Data residency, network and regulatory constraints · When leaving the platform entirely is the correct answer
The track that generates the most anxiety and the most bad outcomes. TFVC and Git disagree about what a branch is, what history means and how large files are handled, so a naive conversion produces a repository nobody wants to use. This module covers the tooling — git-tfs, the Azure DevOps import service, and staged manual approaches — alongside the decisions: how much history to carry, whether to split a monolithic depot, and what to do with binaries.
Topics: Where the TFVC and Git models genuinely diverge · git-tfs, git-tf and the Azure DevOps import service compared · History depth: full conversion, tip-only, or a dated cut · Branch and merge topology, and what does not survive conversion · Splitting a large team project depot into service repositories · Large binaries, Git LFS and repository size management · Rewriting authorship and identity during conversion
XAML builds are a workflow-designer artifact that few remaining engineers can maintain; classic UI-defined builds are better but still live outside the repository. Both need to become pipelines defined as YAML alongside the code. This module reads an existing definition honestly, identifies what it actually does, and rebuilds it as a pipeline with agents, pools, tasks, templates, variable groups and service connections.
Topics: Reading a XAML build process template and extracting its real behaviour · Build controllers and agents versus modern agent pools · Classic definition to YAML conversion, and where the export helps · Tasks, templates and reuse across many pipelines · Variable groups, secrets and service connections · Self-hosted agents for builds that need internal network access · Artifacts, feeds and retention after the move
Classic Release Management modelled deployments as release paths, templates, components and actions driven from the Release Explorer. Multi-stage pipelines model them as stages, jobs and environments with approvals and gates. The mapping is not one to one — particularly around approvals, environment ownership and secrets — and this module works through it with the compliance requirements intact rather than dropped.
Topics: Release paths, templates and actions mapped to stages and jobs · Environments, deployment groups and self-hosted deployment targets · Pre- and post-deployment approvals and automated gates · Segregation of duties and who may approve what · Environment-scoped variables, secrets and secret stores · Rollback, re-deployment and manual intervention · Preserving the deployment audit trail across the change
Migration day, and the weeks either side. Identity mapping from Active Directory accounts to the destination directory, permission and area-path translation, work item migration options and their fidelity limits, the freeze window, the rehearsal, the rollback, and the decision that saves most projects: what stays behind as a read-only archive rather than being carried forward at cost.
Topics: Identity mapping and permission translation to the destination · Work item migration: tooling options and fidelity trade-offs · Attachments, links, history and what commonly breaks · Freeze windows, rehearsal runs and go/no-go criteria · Rollback plan and the point of no return · Standing up a read-only TFS archive for audit and legal retention · Redirecting people and pipelines: bookmarks, remotes and integrations
Migrations take longer than planned, and the legacy instance has to stay healthy throughout. This module covers the operational floor: consistent backups across the configuration, collection and warehouse databases, restore rehearsal, SQL maintenance and database growth, the permission hierarchy and privilege review, service accounts and TLS, and the monitoring that tells you the job agent has stopped before users do.
Topics: Backing up configuration, collection and warehouse databases consistently · Marked transactions and point-in-time restore · Restore rehearsal onto clean hardware · SQL maintenance, index health and database growth control · Permission hierarchy across server, collection, project and area path · Service accounts, TLS and authentication hardening · Monitoring the job agent, queues and activity logs
We rebuild the agenda around the tools you actually run.
Request a custom agendaUse the console, the REST API and direct SQL queries to produce a complete inventory of collections, projects, process models, repositories and builds, then classify each project.
Convert the same branched TFVC path two ways — full history and tip-only — then compare branch topology, repository size, clone time and usability before choosing.
Reverse-engineer what a XAML build definition actually does, rebuild it as a YAML pipeline with a template and variable group, and prove the artifacts match.
Recreate a classic release path as a multi-stage pipeline and demonstrate that an unapproved production deployment is refused and logged.
Build an identity map from a source collection to a destination directory, resolve unmatched and disabled accounts, and translate group permissions without over-granting.
Restore a collection copy, run the full migration path end to end against it, record every error and timing, then present a go/no-go runbook with a rollback trigger.
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
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.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
| 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.