Tableau Server vs Tableau Cloud: Migration Guide and Decision Framework

Every year, thousands of organizations stare at their Tableau Server renewal invoice, glance at Tableau Cloud's marketing page, and ask the same question: "Should we migrate?" It is the analytics equivalent of wondering whether to renovate the house or just move — except the house is full of 4,000 workbooks, half of which nobody has opened since 2023, and the movers charge by the hour.

Here is the short answer: if your organization values agility, predictable costs, and not employing a full-time human just to babysit upgrade cycles, Tableau Cloud is almost certainly the better long-term bet in 2026. Over 70% of new analytics deployments this year are SaaS-first, and the feature gap between Server and Cloud has narrowed to a sliver. But "almost certainly" is doing a lot of work in that sentence. If you operate in a heavily regulated industry, rely on latency-sensitive on-premises data, or have deeply customized your Server infrastructure, the calculus changes.

This guide will walk you through the decision framework, the real costs, the migration process, and the mistakes that separate a smooth transition from a cautionary tale your IT team tells at happy hour.

Understanding the Two Platforms

Before we get into the "should you," let us make sure we agree on the "what." Tableau Server and Tableau Cloud do fundamentally the same thing — they host, share, and govern Tableau content. The difference is who manages the infrastructure underneath.

Tableau Server is the self-hosted option. You install it on your own hardware (or your own cloud VMs), you manage the upgrades, you handle the backups, you troubleshoot the performance issues at 2 AM when the extract refresh schedule collides with someone's 600-row-pivot-table monstrosity. You get maximum control. You also get maximum responsibility.

Tableau Cloud (formerly Tableau Online, rebranded in 2022 — because apparently the old name was not cloud-sounding enough) is the fully hosted SaaS version. Salesforce manages the infrastructure, handles upgrades automatically, and scales resources on demand. You manage content, users, and governance. You do not manage server patches at midnight.

Here is how they compare across the dimensions that actually matter:

Dimension	Tableau Server	Tableau Cloud
Deployment	Self-hosted (on-prem or IaaS)	Salesforce-hosted SaaS
Infrastructure	You own and manage it	Fully managed for you
Upgrades	Manual, scheduled by your team	Automatic, rolling
Scalability	Vertical/horizontal (you provision)	Elastic, managed by Salesforce
Customization	Deep (SSO, extensions, repos)	Moderate (admin-level config)
Release Cycle	Quarterly (when you choose to apply)	Continuous (features land automatically)
Admin Overhead	High (0.5-1.5 FTE typical)	Low (governance-focused)

The Decision Framework: Server or Cloud?

Forget the feature comparison spreadsheets for a moment. The Server-vs-Cloud decision is fundamentally a question about three things: control, compliance, and capacity. Everything else is a derivative.

Choose Tableau Cloud if...

• You are SaaS-first as an organization. If your CRM, ERP, and data warehouse are already cloud-hosted, adding an on-premises Tableau Server is like installing a wood-burning stove in a smart home. It works, technically, but you are fighting the current.
• Your Tableau admin team is small or non-existent. If the person managing Server upgrades is also the person building dashboards, writing SQL, and occasionally fixing the office printer, Cloud will give them their weekends back.
• You want faster access to new features. Tableau Pulse, Tableau Agent, and other AI-powered capabilities land on Cloud first. Server users wait for the next quarterly release and then schedule a maintenance window.
• Predictable costs matter more than maximum control. Cloud pricing is subscription-based and scales linearly. Server pricing involves hardware amortization, hosting costs, admin labor, and the kind of napkin math that makes CFOs nervous.
• Collaboration across locations is a priority. Distributed teams, remote workers, and partner access are natively simpler on a SaaS platform. No VPN gymnastics required.

Choose Tableau Server if...

• Regulatory requirements demand it. Certain industries — healthcare, defense, financial services in specific jurisdictions — have data residency or sovereignty requirements that Cloud's available regions cannot satisfy. If your compliance officer says "the data cannot leave this jurisdiction," that is not a suggestion.
• Most of your data is on-premises and latency-sensitive. If your Tableau extracts pull from on-prem databases with sub-second refresh expectations, introducing Bridge (the connectivity layer for Cloud) adds network hops and potential latency. For high-frequency refresh schedules, this can be meaningful.
• You have deeply customized your Server environment. Custom SSO configurations, repository-level extensions, programmatic backup scripts, bespoke monitoring integrations — if your Server deployment looks more like a custom application than a standard installation, migrating to Cloud means rebuilding those customizations or accepting you cannot replicate them.
• Your infrastructure team is large and capable. If you already have a dedicated platform team managing Server alongside other enterprise tools, the operational overhead is amortized across the stack. The "we don't want to manage infrastructure" argument loses weight when you already have the people doing it.

The best platform decision is the one that matches your organization's actual operating model, not the one that matches your aspirational org chart.

Total Cost of Ownership: The Real Numbers

Everyone wants to talk about licensing costs. Licensing costs are the tip of the iceberg — the part you can see. The part that sinks the ship is everything underneath: hardware, labor, opportunity cost, and the migration itself.

Tableau Cloud Costs

Cloud pricing is relatively straightforward. Creator licenses run $75 to $115 per user per month depending on your contract. Explorer and Viewer tiers are cheaper. You pay for what you use, Salesforce handles the rest.

The hidden costs on Cloud are Bridge infrastructure (if you have on-prem data), potential data egress charges from your cloud data warehouse, and the initial migration project itself.

Tableau Server Costs

Server licensing looks cheaper on paper, but the total cost of ownership tells a different story. You need to factor in:

• Hardware or VM costs — servers, storage, networking, disaster recovery infrastructure
• Admin labor — the 0.5 to 1.5 FTEs managing upgrades, patches, monitoring, and troubleshooting
• Upgrade projects — each major version upgrade is a mini-project with testing, staging, and rollback planning
• Security and compliance — patching, vulnerability scanning, audit preparation
• Opportunity cost — what could those admin hours be spent on instead?

Industry data consistently shows that Tableau Cloud delivers 15% to 25% lower TCO compared to self-hosted Server environments. Some estimates put the difference as high as 20% to 50% for organizations that are honest about their fully loaded admin costs (and most are not — it is surprisingly easy to forget that the person who "just handles Tableau on the side" is spending 20 hours a week on it).

Migration Costs

This is the part people underestimate. A Tableau Server to Cloud migration is not a drag-and-drop operation. It is a structured project with real costs:

• Small deployments (under 300 workbooks): $80K to $120K
• Mid-market (300 to 1,500 workbooks, single-region Bridge): $120K to $200K over 8 to 16 weeks
• Enterprise (1,500+ workbooks, multi-region, complex permissions): $200K to $300K+ over 16 to 26 weeks

The natural trigger for migration is when your Server infrastructure is due for a major hardware refresh or version upgrade. The budget you would have spent on that refresh becomes the budget for migration — and unlike the refresh, the migration eliminates ongoing infrastructure costs permanently.

The Five-Phase Migration Framework

We have seen migrations go well and we have seen them go sideways. The difference is almost always process discipline, not technical complexity. Here is the framework that works.

Phase 1: Assessment and Readiness (Weeks 1-3)

Before you migrate anything, you need to understand what you have. This is the content rationalization phase — and skipping it is the single most common mistake in Tableau migrations.

Audit your Server environment:

• Content inventory — How many workbooks, data sources, flows, and projects exist? How many are actively used? (Spoiler: if you have 5,000 workbooks, roughly 60% of them are unused. We did not make that number up — it is consistently what we find.)
• Data source mapping — Which data sources are cloud-resident and which are on-premises? This determines your Bridge requirements.
• Permissions audit — Document your current permissions model. "Migrate as-is" sounds efficient until you realize you are migrating three years of permission debt along with the content.
• Custom configurations — SSO setup, embedding configurations, REST API integrations, custom extensions, scheduled scripts.
• User adoption data — Who uses what, how often, and when? This data drives your migration priority order.

The output of this phase is a migration scope document and a content rationalization plan. The content you do not migrate is just as important as the content you do.

Phase 2: Architecture and Licensing Alignment (Weeks 3-5)

With the assessment complete, you can now design the target state:

• Licensing model — Map your current Server licenses to Cloud license types. The licensing delta is typically neutral to mildly favorable, but the mix of Creator, Explorer, and Viewer licenses may shift.
• Site structure — Design your Cloud site hierarchy. Cloud uses a flat site model, which is different from Server's multi-site capability. Plan accordingly.
• Governance framework — Define content certification standards, naming conventions, and ownership models for the Cloud environment.
• Authentication — Configure SSO, MFA, and user provisioning for Cloud. If you are using SAML or OpenID Connect on Server, the Cloud configuration is similar but not identical.

Phase 3: Secure Connectivity Planning (Weeks 4-6)

If any of your data lives behind a firewall, this phase is where Tableau Bridge enters the picture. Bridge is the connectivity layer that allows Tableau Cloud to access on-premises data sources — think of it as a secure tunnel between your data center and Cloud.

• Bridge deployment — Typical setups use 1 to 3 Bridge clients per region for redundancy. Each client needs a dedicated Windows machine (or VM) with network access to your data sources.
• Network configuration — Firewall rules, proxy settings, and DNS resolution for Bridge clients.
• Refresh scheduling — Bridge supports live connections and scheduled extracts, but the scheduling model differs from Server. Plan your refresh windows.
• Monitoring — Set up alerting for Bridge health. A failed Bridge client means stale data, and stale data means angry stakeholders wondering why last night's numbers are not in the dashboard (and sending you a Slack message about it at 7:43 AM).

A critical note: any migration vendor that scopes Bridge as "phase two" or "we'll figure that out later" is waving a red flag so large you could see it from the Cloud data center. Bridge connectivity is foundational, not optional.

Phase 4: Pilot Migration (Weeks 6-10)

Do not migrate everything at once. Start with a pilot group — ideally a team whose content is relatively self-contained, whose data sources are well-understood, and whose stakeholders are patient enough to provide feedback without filing an incident ticket every time a dashboard loads half a second slower.

• Migrate pilot content — Use the Tableau Migration Tool or the REST API to move workbooks, data sources, and projects.
• Validate content parity — Every workbook, every calculated field, every filter action. Visual differences, data discrepancies, and broken data source connections all surface here.
• Performance benchmarking — Compare load times, refresh durations, and concurrent user performance against Server baselines.
• User acceptance testing — Have actual users (not just the migration team) work in Cloud for at least two weeks. Their feedback will surface issues your technical testing missed.
• Iterate — Fix issues, update the migration playbook, and document lessons learned before scaling to the full migration.

Phase 5: Full Rollout and Decommissioning (Weeks 10-16)

With the pilot validated, scale the migration across the organization in waves. Prioritize by business criticality and data source complexity — migrate the simplest, most critical content first.

• Wave-based migration — Typically 3 to 5 waves, each taking 1 to 2 weeks.
• Parallel run period — Keep Server and Cloud running simultaneously for 2 to 6 weeks after the final wave. This is your safety net.
• User communication — Clear, frequent updates. Migration fatigue is real, and the cure is transparency, not silence.
• Server decommissioning — Once parallel run is complete and stakeholders sign off, decommission Server. Cancel hardware leases, terminate VMs, and update DNS records.
• Post-migration optimization — Tune Cloud performance, clean up migrated permissions, and establish ongoing governance practices.

Tableau Bridge: The Connector You Cannot Ignore

Bridge deserves its own section because it is simultaneously the most important and most underestimated component of a Cloud migration. If you skip Bridge planning, you are building a house without connecting the plumbing. Everything looks great until someone turns on the faucet.

Bridge is a lightweight client application that runs on a Windows machine inside your network. It establishes an outbound connection to Tableau Cloud (no inbound firewall rules required), enabling Cloud to refresh data from on-premises sources like SQL Server, Oracle, or file shares.

Bridge Architecture Best Practices

• Redundancy — Deploy at least 2 Bridge clients per region. A single point of failure on your data pipeline is not a "calculated risk" — it is an incident waiting for a Tuesday morning.
• Dedicated resources — Bridge clients should run on dedicated VMs, not shared application servers. Extract refreshes are resource-intensive, and contention kills performance.
• Connection pooling — Distribute data source connections across Bridge clients to balance load and avoid bottlenecks.
• Monitoring and alerting — Use Tableau's built-in Bridge monitoring plus external tools (Datadog, Grafana, whatever your stack uses) to track refresh success rates, duration trends, and client health.
• Version management — Bridge clients auto-update, but you should still track versions and validate updates in a staging environment first.

Permissions and Governance: The Silent Migration Killer

Here is a scenario we see too often: a migration team diligently moves 2,000 workbooks to Cloud, validates that they all load correctly, and declares victory. Then, on Monday morning, 47 people open support tickets because they cannot see dashboards they used to access daily. The workbooks migrated fine. The permissions did not.

Permissions migration is where the phrase "migrate as-is" becomes dangerous. Server permissions accumulate like sediment — layers of ad hoc grants, inherited project permissions, and one-off exceptions that nobody documented because "we'll clean this up later." Migrating that mess to Cloud does not solve the problem. It relocates it.

A Better Approach

• Audit before you migrate. Map every permission to a business justification. If you cannot explain why Marketing Intern #3 has Creator access to the Finance project, fix it now.
• Standardize on groups. Individual user permissions are technical debt. Migrate to group-based permissions aligned to roles and departments.
• Document the governance model. Who approves new projects? Who certifies data sources? Who reviews permissions quarterly? If the answer to any of these is "nobody, currently," the migration is your opportunity to fix that.
• Test permissions explicitly. Create test accounts for each permission role and verify access to every project and workbook in Cloud. Automated testing scripts using the REST API can accelerate this significantly.

Content Rationalization: Migrating Less to Move Faster

The most common scope error in Tableau migrations is migrating everything. We have audited environments where 5,000 workbooks existed and 60% had not been opened in over a year. Migrating unused content is like packing boxes of junk for a house move — it costs time, money, and shelf space, and you will never open those boxes again.

The Rationalization Process

• Usage analysis — Pull view counts, last-accessed dates, and unique user counts from Server's repository database. Any workbook with zero views in 12 months is a candidate for archival, not migration.
• Owner outreach — Contact workbook owners for borderline cases. "Do you still use this?" is a simple question with a powerful answer. (The answer is usually "I forgot that existed.")
• Archive, don't delete — Export unused workbooks as .twbx files to a shared drive or object storage. If someone needs them later, they can be republished. Nobody has ever come back for them, but the option provides political cover.
• Consolidate duplicates — Multiple teams building similar dashboards from similar data is a governance failure, not a productivity feature. Use the migration as the forcing function to consolidate.

We once audited an organization with 12 different "Weekly Revenue Dashboard" workbooks across 8 departments. Three of them were correct. Two were close. The rest were works of confident fiction.

Performance Considerations and Optimization

Performance is where the Server-vs-Cloud debate gets nuanced. Server gives you direct control over hardware resources, and when you know what you are doing, you can tune performance precisely. Cloud abstracts that away — you trade tunability for managed scalability.

What Performs Better on Cloud

• Concurrent user scaling — Cloud's elastic infrastructure handles traffic spikes without manual intervention. No more "the server is slow because Finance just published their month-end reports and 200 people hit it simultaneously."
• Cloud-native data sources — If your data lives in Snowflake, BigQuery, Redshift, or Databricks, Cloud-to-cloud connectivity is fast and direct. No Bridge required, no extra network hops.
• Feature delivery — Performance improvements and new features land on Cloud first and continuously.

What Performs Better on Server

• On-premises data with low latency requirements — Direct database connections on the same network will always be faster than Bridge-mediated connections.
• Custom resource allocation — If you need to dedicate specific CPU and memory to background extract jobs versus interactive queries, Server gives you that granularity.
• Very large extracts — Multi-gigabyte extracts refresh faster when the Server and database share a high-speed network.

Optimization Tips for Cloud Migration

• Move data to the cloud first. The single biggest performance improvement for Cloud is eliminating Bridge by migrating your data warehouse to a cloud platform. Bridge is functional, but it is always slower than direct cloud-to-cloud connectivity.
• Optimize extract sizes. Cloud has extract size limits and refresh duration limits. If your extracts are bloated, the migration is the right time to filter, aggregate, and slim them down.
• Leverage Accelerator. Tableau Cloud's query acceleration feature can dramatically improve performance for complex dashboards that aggregate large datasets.
• Right-size refresh schedules. Not every dashboard needs hourly refreshes. Match refresh frequency to actual business requirements, not "we've always done it that way."

Security and Compliance Considerations

Security is often cited as the reason to stay on Server. And for some organizations, it is a legitimate reason. But for most, it is a perception issue — the instinct that "our servers are more secure because we can see them" does not hold up under scrutiny.

Tableau Cloud runs on AWS infrastructure with SOC 2 Type II, ISO 27001, and FedRAMP (Moderate) certifications. Data is encrypted at rest and in transit. Salesforce's security team is larger than most organizations' entire IT departments.

That said, there are legitimate compliance scenarios where Server is the right choice:

• Data residency requirements — If regulations require data to remain within a specific geographic boundary and Cloud does not have a region there, Server is your only option.
• Air-gapped environments — Defense and certain government deployments require networks with no internet connectivity. Cloud is, definitionally, not an option here.
• Custom audit requirements — If your compliance framework requires direct database-level audit logs, Server's PostgreSQL repository gives you that access. Cloud provides audit logs through its admin interface, but with less granularity.
• BYOK encryption — If you need to manage your own encryption keys for data at rest, Server provides that capability. Cloud uses Salesforce-managed keys with customer-managed key options available on specific tiers.

User Adoption and Change Management

Technical migration is the easy part. (Relatively speaking. "Easy" is doing some heavy lifting in that sentence.) The harder part is getting hundreds or thousands of users to change how they access their dashboards, where they save their work, and how they think about the analytics platform.

Change Management Strategies That Work

• Communicate early and often. Announce the migration well before it starts. Explain the why, the what, and the timeline. People resist surprises more than they resist change.
• Identify champions. Find power users in each department and involve them in the pilot. They become your first line of support and your most credible advocates.
• Provide training. Cloud's interface is similar to Server's, but there are differences in navigation, sharing, and data connectivity. A 30-minute training session prevents a week of support tickets.
• Set up a dedicated support channel. A Slack channel, a Teams group, a shared inbox — whatever your organization uses. Give people a place to ask questions without feeling like they are filing a formal IT request.
• Measure adoption. Track login rates, content access patterns, and support ticket volume post-migration. If adoption drops, investigate immediately. Silence is not satisfaction — it is often people reverting to downloading data and building their own spreadsheets, which is exactly the problem Tableau was supposed to solve.

Red Flags When Selecting a Migration Partner

Not every organization has the internal expertise to run a Tableau migration. If you are engaging a consulting partner, here are the warning signs that should make you reconsider:

• No content rationalization phase. If the proposal is "we'll migrate everything," you are paying to move digital junk. A good partner challenges what should migrate, not just how.
• Bridge scoped as "phase two." Bridge is not a post-migration add-on. If your data connectivity is not working from day one, your migration is not complete from day one.
• No Tableau Cloud Administrator certifications on the team. This is a specialized skill set. General Tableau expertise is not the same as Cloud migration expertise.
• Permissions treated as "migrate as-is." As discussed earlier, this is a recipe for post-migration chaos. A good partner insists on a permissions audit and cleanup.
• No parallel-run or cutover plan. A migration without a rollback strategy is not a migration. It is a bet. And the stakes are your organization's access to its own data.

Timeline Expectations: Setting Realistic Goals

Timelines vary dramatically based on scope, and the most common mistake is underestimating duration. Here is what realistic looks like:

• Small (under 300 workbooks, minimal Bridge) — 6 to 10 weeks
• Mid-market (300 to 1,500 workbooks, single-region Bridge) — 8 to 16 weeks
• Enterprise (1,500+ workbooks, multi-region, complex governance) — 16 to 26 weeks
• Large enterprise (5,000+ workbooks, multi-site, global deployment) — 12 months or more

The primary driver of duration is not the number of workbooks — it is the cleanliness of your content and permissions. An organization with 500 well-governed workbooks will migrate faster than one with 300 ungoverned ones, because rationalization, permissions cleanup, and data source mapping take longer than the actual migration step.

The AI and Innovation Angle

Here is a factor that rarely appears in migration guides but matters more every quarter: Salesforce is investing disproportionately in Cloud-first features, particularly around AI and machine learning.

Tableau Pulse (natural language data insights), Tableau Agent (AI-driven analytics), and Einstein integration all land on Cloud first. Some of these features may never come to Server, or will arrive significantly later. If your analytics strategy includes leveraging AI for automated insights, anomaly detection, or natural language querying, Cloud is not just a deployment preference — it is a prerequisite.

For organizations that treat analytics as a strategic differentiator rather than a reporting utility, falling behind on AI-powered features is a competitive risk. Server gives you stability. Cloud gives you the future.

Hybrid Deployment: The Middle Path

Not every decision is binary. Some organizations run hybrid deployments — keeping sensitive or high-performance workloads on Server while moving the majority of content to Cloud. This can be a pragmatic interim strategy, particularly for organizations with regulatory constraints that apply to only a subset of their data.

The trade-off is complexity. Hybrid means managing two environments, two permission models, and two sets of users who need to know where to find what. It also means two licensing contracts, which can erode the cost savings that motivated the Cloud move in the first place.

Treat hybrid as a transition state, not a destination. Set a timeline for consolidation, and revisit annually whether the constraints keeping content on Server still apply.

Frequently Asked Questions

How much does migrating from Tableau Server to Tableau Cloud cost?

Migration projects typically range from $80K to $300K depending on Server complexity, content volume, and semantic model cleanliness. Most mid-market migrations (300 to 1,500 workbooks with a single-region Bridge setup) land between $120K and $200K over 8 to 16 weeks. The natural budget trigger is an upcoming hardware refresh or major Server version upgrade — the cost you would have spent maintaining Server becomes the investment in eliminating it.

How long does a Tableau Server to Cloud migration take?

Standard migrations with 300 to 1,500 workbooks take 8 to 16 weeks. Enterprise-scope projects run 16 to 26 weeks, and the largest deployments can exceed 12 months. The primary duration driver is content cleanliness — how much rationalization and permissions cleanup is needed before migration begins. Organizations that invest in pre-migration content governance consistently finish faster and with fewer post-migration issues.

What is Tableau Bridge and do I need it?

Tableau Bridge is a client application that keeps data in Tableau Cloud synchronized with on-premises data sources. If any of your data lives behind a corporate firewall or VPN, you need Bridge. Typical deployments use 1 to 3 Bridge clients per region for redundancy. Bridge is not optional if you have on-prem data — it is the plumbing that makes Cloud work with your existing data infrastructure.

Is Tableau Cloud cheaper than Tableau Server?

In most cases, yes. Organizations typically see 15% to 25% lower total cost of ownership with Tableau Cloud once you factor in eliminated hardware, reduced admin labor, and automatic upgrades. However, very large deployments with heavy on-premises data may see a narrower margin or even parity due to Bridge infrastructure costs. The most honest cost comparison includes admin FTE hours, which many organizations undercount on the Server side.

Can I run Tableau Server and Tableau Cloud simultaneously during migration?

Yes, and you should. A parallel-run period is a best practice for enterprise migrations. This allows teams to validate content parity, test Bridge connectivity, and build user confidence before decommissioning Server. Most organizations run parallel environments for 2 to 6 weeks. The key is setting a firm cutover date — parallel run without a deadline becomes permanent dual management, which is the worst of both worlds.

What are the main feature gaps between Tableau Server and Tableau Cloud in 2026?

The gap has narrowed significantly since 2022. Tableau Cloud now supports most Server features including data management add-on, advanced analytics, and Tableau Pulse. The remaining differences center on deep infrastructure customization, certain custom authentication configurations, and specific extension framework capabilities that require direct server access. For the vast majority of use cases, Cloud has feature parity or superiority.

When should I NOT migrate to Tableau Cloud?

Stay on Server if you operate in a highly regulated industry with strict data residency requirements that Cloud regions cannot satisfy, if most of your data is on-premises with latency-sensitive refresh schedules that Bridge cannot match, or if you rely on deep infrastructure customization that Cloud's managed environment does not support. Also stay if you are planning a broader platform evaluation — migrating to Cloud only to switch to Power BI six months later is an expensive detour.

The Bottom Line

For most organizations in 2026, the question is not whether to move to Tableau Cloud, but when. The economics favor it, the feature set supports it, and the AI-powered future of analytics demands it. The 30% of organizations still evaluating are not wrong to be cautious — they are wrong to be indefinitely cautious.

The migration itself is a significant project, but it is a bounded one. Eight to sixteen weeks of focused effort in exchange for years of reduced operational overhead, automatic feature delivery, and a platform that scales without emergency weekend maintenance windows. That is a trade most organizations should take.

The key is doing it methodically: rationalize your content, plan your Bridge connectivity, clean your permissions, pilot before you scale, and run parallel until you are confident. Skip any of those steps and the migration joins the long list of IT projects that were "almost done" for six months.

If you are staring at a Server renewal and wondering whether this is the year, it probably is. And if you want help making the transition without the false starts and scope creep, that is exactly what we do.