TeamCity Professional limits: upgrade to Enterprise or move to open source

TeamCity Professional stops at 100 build configurations, 10 pipelines and 3 agents, and blocks new builds when agents exceed licenses. This page explains the choice between buying Enterprise and moving to Jenkins or Woodpecker CI.

Book a callTalk to us
On this page

Why TeamCity Professional limits push teams to decide between Enterprise and open source

Teams that have outgrown TeamCity Professional limits face two paths: buy Enterprise or additional agent licenses and keep TeamCity, or move the same builds to self-hosted Jenkins or Woodpecker CI. The Professional edition stops at 100 build configurations, 10 pipelines and 3 agents, and once connected agents exceed the licenses held, TeamCity blocks new builds. That ceiling tends to arrive during a busy release week, which forces the decision before the team has measured what its estate actually needs.

The limit comes from licensing and capacity, so it does not show that the builds cannot run anywhere else. The right answer depends on three factors: how many agents must run at peak, how many Windows builds the team depends on, and how heavily it relies on build chains and snapshot dependencies. Woodpecker CI runs workflows in containers and connects to several forges, which suits Linux container builds. Jenkins runs on many platforms through its agents and plugins, but its pipelines are written in a different model. Test your Windows and build chain requirements against each engine before choosing.

Start with an inventory: count the agents active in a normal week and at peak, list the build configurations still in use, and note which ones need Windows or chained builds. Ask the vendor for a written quote that states whether Enterprise and agent licenses are annual, how additional agents are billed, and what happens when usage grows mid-term. On the open-source side, the cost is mostly the engineering time to build, maintain and back up the server and agents, which recurs as long as the platform runs. Compare both quotes against that inventory before committing to either path.

What the Professional ceiling requires from your CI estate

TeamCity Professional limits your CI estate on four fronts at once: how many build configurations and pipelines you run, how many agents stay connected, how licensing grows with them, and what you can take with you if you leave. Each card below is a decision to make before a limit blocks a build, whether you buy Enterprise or move to open source.

Build configurations and pipelines

Professional allows 100 build configurations and 10 pipelines. Count both from your versioned settings export so the number reflects what is in the repository. Teams that keep adding small projects often reach the pipeline ceiling before the configuration ceiling, so track both figures every month. Confirm in the TeamCity documentation how templates and build chains count toward these limits before you rely on them. If you stay on Professional, consolidate duplicated configurations now. If you move to Jenkins or Woodpecker CI, the same inventory becomes your list of pipeline files to write.

Agent counts and licenses

Professional allows 3 agents, and TeamCity blocks new builds when connected agents exceed the licenses you hold. Compare the agent count with peak parallel demand, such as the hour before a release, because average load hides the problem. Autoscaling or ephemeral build hosts can push the count above the limit without anyone noticing, so check which agents register automatically. On Enterprise, every additional agent is a recurring license line. Jenkins and Woodpecker CI carry no per-agent license, but you pay for the machines, their upkeep and the staff who run them.

Licensing that scales with growth

Enterprise is licensed per agent, so cost rises with each build machine you add. Ask the vendor how agent licenses are added, whether unused licenses carry over, and how billing works if you exceed the licensed count mid-term. Model two scenarios: the agent count you run today and the peak you expect after the next product launch or acquisition. Open-source engines remove the per-agent license line, but their cost recurs in infrastructure, plugin maintenance and engineering time. Write those recurring items into the comparison over the same horizon so the two options are measured on equal terms.

Handing off build history and secrets

Hosted CI services hold deployment secrets and keep artifacts for limited periods, so an exit needs both exported before cutover. Secret values often cannot be read back: GitHub returns only secret names, and CircleCI states that variable values are not readable after they are set. After CircleCI's January 4, 2023 incident, customers were told to rotate secrets, which is the same step you should plan for any move. Confirm whether TeamCity secure values can be exported, and if they cannot, plan to re-enter and rotate them in the new system. Export build history and logs before you cancel the subscription.

How TeamCity Enterprise, Jenkins and Woodpecker CI compare against the limits

TeamCity Enterprise keeps the same server, build chains and agent model, and lifts the Professional ceilings through licensing. Your limits become whatever your Enterprise terms cover, so the core questions are how many build configurations, pipelines and agents you need and what each costs at renewal.

  • Ceilings lifted by license: Professional stops at 100 build configurations, 10 pipelines and 3 agents. Enterprise replaces those caps, but get the exact terms in writing from JetBrains before you plan around them.
  • Agent licensing recurs: Enterprise is licensed per agent, so every added build agent is a recurring line item. Ask what happens when agent count exceeds the license and whether unlicensed agents can still connect.
  • Familiar features stay: Build chains, IDE integration and Windows agents remain part of the TeamCity model, which matters if builds depend on Windows-only tooling. Confirm these features are included in the edition you buy.
  • Operations stay with you: You still run the server, database, backups and upgrades inside your own infrastructure. Ask how upgrades are supported for your version and what true-up billing applies when agent counts grow.

Before renewal, export your Kotlin DSL or XML settings and build history, then request a quote that lists Enterprise terms, agent count and true-up rules for the next term.

How to move off the Professional limits without losing build history

This sequence inventories TeamCity configurations, picks a target per project group, builds a parallel environment, and cuts over only after build history, artifacts and secrets are accounted for.

  1. Inventory every build configuration with versioned settings

    Enable versioned settings on the TeamCity server so the project tree, build configurations, templates, parameters and VCS roots are committed to a .teamcity directory in Kotlin DSL or XML. The TeamCity administrator and a lead developer for each project should review the export and mark which configurations are active, which are dormant and which depend on each other through snapshot dependencies or build chains. Done means the repository holds a complete, reviewed inventory that a second person can read without opening the TeamCity UI.

  2. Decide the target for each project group

    Group the inventory by team, product or risk level, then choose for each group whether to stay on TeamCity with Enterprise or agent licenses, move to self-hosted Jenkins, or move to Woodpecker CI. Count build configurations, pipelines and agents per group against the Professional limits to see which groups force the decision. Record the decision, the owner and the reason in the migration plan so later reviewers can see why a group moved or stayed.

  3. Export build history, logs and artifacts before any tier change

    Before you change the license tier or retire agents, export build history, logs and build artifacts that you need to keep, because hosted CI services in general keep artifacts for limited periods. Store the exports in your own storage with retention rules that match your audit obligations. Confirm with your compliance lead which records must survive the move. Done means each retained build has a stored log and artifact set that can be found by project and build number.

  4. Inventory secrets and plan re-entry

    List every parameter marked as a password or secure value, every deploy key, token and certificate referenced by the build configurations, and the systems each one unlocks. Secret values usually cannot be read back from a CI platform once stored, so plan to re-enter them from the original password manager or key store, and rotate any credential whose value is unknown or shared. Done means each secret has a named owner, a source of truth outside the CI server and a rotation decision.

  5. Stand up the target server and agents

    For Jenkins, install the controller on a supported Java version, keep builds on dedicated agents and place configuration, plugins and secrets under a backed-up $JENKINS_HOME. For Woodpecker, deploy the server with a production database, connect it to your forge, and run agents on Docker or Kubernetes, adding the optional autoscaler only if you need cloud VMs for bursty demand. Done means a test pipeline runs on an agent, a restore of the controller or server configuration has been rehearsed, and access controls match the TeamCity setup.

  6. Translate pilot projects and run them in parallel

    Convert a small set of representative configurations into Jenkinsfiles or Woodpecker YAML, then run them alongside TeamCity on the same commits. Compare build results, test counts, artifact outputs and deployment effects, and note every difference in environment variables, agent tooling or plugin behavior. Done means the pilot builds match the TeamCity results for an agreed set of commits, and the gaps you could not close are logged with an owner.

  7. Cut over group by group and keep a rollback path

    Move each project group to the new platform in the order you set during planning, switching triggers and deployment credentials only after its pilot passes. Keep TeamCity read-only and its agents available for the agreed rollback window so that a failed group can return to its previous build path. Done means every migrated group has a recorded cutover date, a successful production build on the new platform and a confirmed rollback decision for TeamCity.

  8. Retire TeamCity licenses and agents deliberately

    Once every group has cut over and the retention window has closed, remove remaining agents, revoke TeamCity tokens and cancel or downgrade the license in line with your contract terms. Confirm with the vendor what happens to your data and license records at that point. Done means no active builds or deployments depend on TeamCity, the exported archive is verified and the license change is documented.

Questions buyers ask before choosing Enterprise or open source

What drives the cost of TeamCity Enterprise compared with self-hosted Jenkins or Woodpecker CI?

TeamCity Enterprise carries recurring license fees tied to agents and edition, and you still run the server and agent hosts. Jenkins is distributed under the MIT License and Woodpecker CI under Apache-2.0, so neither charges a license fee, and the cost moves to infrastructure, plugin upkeep, upgrades, backups and the staff time to run them. Compare these components side by side: licenses or support contracts (recurring), server and agent compute (recurring), plugin and version maintenance (recurring), and migration effort (one-time). Ask TeamCity for current Enterprise and agent pricing in writing, and ask for a written scope before comparing totals. DeployOpen does not publish a price list, so any quote follows from the agreed scope.

How long does a move from TeamCity to Jenkins or Woodpecker CI take?

The duration depends on the size and complexity of what you have built in TeamCity, so it is set in the written scope rather than assumed up front. The main drivers are the number of build configurations and build chains, shared templates, the mix of Linux and Windows agents, the number of secrets to re-create, and the integrations that depend on TeamCity reports or triggers. The most reliable starting point is an inventory of your versioned settings, which lets the team count and classify each configuration before agreeing a timeline. Ask any provider to tie the timeline to that inventory and to the parallel-run period that comes before cutover.

What does a CI migration need from our own team?

The work needs named people who can grant access and make decisions. Expect to provide read access to the source forge, administrative or project access to the repositories that will trigger builds, and access to the hosts that will run agents. Secret owners must re-enter credentials in the new system, because CI secret values generally cannot be exported from one platform to another. Pipeline owners should review converted pipelines, approve parallel runs, and sign off on cutover. Release and security stakeholders should confirm the new deployment credentials and approval gates before TeamCity is retired. Confirm these responsibilities in the written scope so nobody discovers them during cutover.

Can our engineers migrate from TeamCity without outside help?

A capable in-house team can migrate a small estate alone, but the answer depends on skills you already have. Woodpecker CI uses YAML workflows that run each step in a container image, so teams familiar with containers and pipeline YAML can adopt it quickly. Jenkins asks more of the team: Jenkinsfile design, plugin selection and approval, controller and agent administration, and regular LTS upgrades. Many organizations split the work, keeping pipeline conversion in-house while bringing in outside help for the platform build, hardening, backups and cutover. Assess your staff's Jenkins and container experience honestly before choosing a split.

Does Woodpecker CI cover our Windows builds and TeamCity-specific features?

Confirm this before you commit, because Woodpecker's documented agent backends are Docker, Kubernetes and the local machine, and the supplied material does not establish Windows agent support. Ask the vendor or test in your own environment before you assume it. Also map any TeamCity features your teams depend on, such as build chains, snapshot dependencies, IDE integration and certain reporting, to the equivalent in the target engine. Jenkins can distribute work across multiple machines, and its plugin catalog is large, but each plugin must still be checked against your requirements. Record every feature gap in the inventory so the decision rests on evidence.

Will open-source CI stay supported and upgradable over the coming years?

Support depends on the release cadence and on your upgrade plan. Jenkins chooses a new LTS baseline every 12 weeks and ships three LTS releases per baseline, and its Java support policy lists dated end-of-support points for each Java version, so the platform needs a planned upgrade cycle. Woodpecker publishes regular releases, with version 3.19.0 released on October 7, 2026, and teams should track them the same way. Ask any provider how upgrades, plugin updates and security patches are tested and scheduled. Ongoing support and upgrades are available as retainers, and the scope should state which versions are covered.

What should a fixed-scope quote for a CI migration include?

A useful quote lists what is in scope, what is excluded, how success is measured, and when each deliverable arrives. Ask for the following items to appear in writing: an inventory of build configurations, chains, templates, agents and secrets; the target platform and its version; the mapping rules for each construct; the plan for secret re-entry and artifact or build history export; the parallel-run period and cutover steps; documentation and handover; acceptance criteria; and whether post-migration support is a separate retainer. Also ask how changes to scope are handled and who signs off each stage. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How do we keep builds running while both CI systems operate during the switch?

Run both systems in parallel until the new pipelines have proven themselves, and cut over one project group at a time. Woodpecker can connect to GitHub, GitLab, Gitea, Forgejo, Bitbucket and Bitbucket Datacenter, so builds can move in-house without moving repositories, which keeps source hosting out of the change. Keep TeamCity available for rollback until each group has passed its acceptance criteria. Plan the order of cutover around release calendars and freeze windows, and record every pipeline's owner. Review the Woodpecker forges overview to confirm your forge is supported and note that multi-forge setups on one server are still experimental.

Evidence to keep when you change CI platforms

A change board or auditor will want to see what the TeamCity estate contained, what moved, and who approved each step. The cards below cover the records to keep before, during and after a move, whether you buy Enterprise or migrate to open source. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any opinion.

Versioned configuration inventory

Keep the versioned settings export as the baseline of what TeamCity ran: the .teamcity directory in Kotlin DSL or XML, with its commit history. Record the commit hash that was used as the cutover source so a reviewer can see exactly which build configurations, parameters and templates were in scope. Note any configuration that lived only in the UI and was never versioned, since those items often disappear silently during a move.

Build history and artifact export

Export build history, logs and artifacts from TeamCity before the subscription or agent licence changes, and store them in a location you control. Record the date range, the number of builds exported and any builds that failed to export. Artifacts are the item most likely to be lost, so keep a checksum for each exported file.

Secret re-entry log with owners

TeamCity secure parameters cannot be read back once stored, so each secret must be re-entered in the new platform by a named person. Log each secret by name, not value, with the system it authenticates to, the owner who supplied it and the date it was re-entered. Rotate any credential that could not be confirmed as moved, and have the owner sign off on the entry.

Pipeline cutover record

Record which TeamCity build configurations and build chains were switched to Jenkins, Woodpecker CI or GitLab CI/CD, in what order, and under which change ticket. Include the rollback step for each pipeline and the first successful run on the new platform. Keep TeamCity runs available until each cutover is confirmed, and record when they were disabled.

Licence and agent counts before and after

Capture the TeamCity Professional position at the start of the change: build configuration count, pipeline count and connected agent count against the limits of 100 build configurations, 10 pipelines and 3 agents. Record the same counts for each option you evaluate, whether that is Enterprise with agent licences or the open-source target. Attach the agent inventory with hostnames and owners so the board can reconcile what was paid for against what ran.

Agent and runner access review

List every machine that ran TeamCity builds, the credentials each one held and who could reach it. Once agents are replaced by Woodpecker agents, Jenkins agents or GitLab Runners, review the new hosts in the same way and record the access decisions. This shows that the new build infrastructure was not given broader access than the old one.

How Jenkins and Woodpecker CI licensing affects a long-term decision

The first question for a long-term decision is which license governs the engine you adopt. Jenkins is distributed under the MIT License, a permissive license that lets your organization run, modify and distribute the software without paying the project for the right to do so. Woodpecker CI is licensed under Apache-2.0, which is also permissive and carries an explicit patent grant. Woodpecker exists because of a change in the other direction: Drone CI moved from Apache 2.0 to a proprietary license, and the community forked Drone 0.8 in 2019 as Woodpecker. Drone is now managed by Harness under the Polyform Small Business license, so a team that adopted Drone for its open terms had to re-evaluate. Read the license file in each repository yourself, and check whether any plugin, extension or add-on you depend on carries different terms.

Licensing change risk applies to any CI vendor, including the open-source projects you choose. A permissive license protects the code you already have, but it does not guarantee that a project will keep developing, so weigh governance and maintainer activity alongside current price. Ask who controls the project, whether it has a foundation or multiple companies contributing, how many maintainers are active, how often releases ship, and how security fixes are published. Jenkins is one of the projects hosted by the Continuous Delivery Foundation, and Woodpecker is maintained by a community project. Those are different governance models, and each carries its own continuity risk. Record the answers as part of the decision, and revisit them at each renewal of your support arrangement.

Vendor changes in this market are already happening. Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products, with sales to new customers ending March 30, 2026 and end of life on March 28, 2029, and it has stated that Bitbucket and Bamboo Data Center will continue beyond that date under a Bitbucket Hybrid License. Separately, Atlassian and GitHub have both moved to meter self-hosted runners. Commercial terms can change on a published schedule or with little notice, so write down which contract terms, support windows and licensing metrics your TeamCity Enterprise purchase depends on. Whichever engine you choose, keep your pipeline definitions in your own Git repositories and confirm that your build history and secrets can be exported before you commit.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source CI platforms inside your own infrastructure, so the move off TeamCity Professional limits is handled as a fixed-scope engagement with written deliverables. We start from your existing TeamCity configuration and agree in writing what moves, what stays and what gets retired.

How we scope

  • Inventory every build configuration, pipeline, agent and build chain against the Professional limits before any choice between Enterprise and open source.
  • Agree in writing which projects move to Jenkins or Woodpecker CI, which stay, and which are retired.
  • Confirm how secrets, build artifacts and build history will be exported, since hosted and vendor-held values often cannot be read back out.

How we build

  • Set up the chosen CI engine in your own cloud account, data center or air-gapped network, with agents sized to your workloads.
  • Rebuild pipelines from the exported TeamCity settings and test them against the forge hosting your repositories.
  • Configure secrets handling, access control and backups of the controller state, such as $JENKINS_HOME for Jenkins, before cutover.

How we hand over

  • Deliver written documentation of the architecture, pipeline definitions, agent setup and the operating runbook for your team.
  • Provide a mapping of each former TeamCity build configuration to its replacement, with the decisions recorded.
  • Prepare the controls and evidence your compliance assessors will ask for, while independent auditors and certification bodies issue any reports.

How we support

  • Ongoing support, plugin and platform upgrades, and continuous testing are available as retainers after handover.
  • Ask for the quote to list each component in scope, the one-time migration work and the recurring support tasks separately.
  • Confirm with the vendor and your own environment which current license limits and agent rules apply before the scope is signed.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com