SQL Server performance tuning, cloud migration, SSIS/SSRS/SSAS development, and Always On high availability — from a team with 20+ years of production SQL Server experience. FreedomDev is based in Zeeland, Michigan. We fix slow queries, migrate on-premise databases to Azure SQL, and build the ETL pipelines and reporting infrastructure that enterprises depend on. Projects range from $10K tuning engagements to $500K+ full-stack database modernizations.
SQL Server runs the transactional backbone of more enterprises than any other commercial database engine. Your ERP processes orders through it. Your CRM stores every customer interaction in it. Your BI dashboards query it. Your compliance reports pull from it. When SQL Server is healthy, nobody thinks about it. When it is not, the entire business feels it — slow page loads, timeout errors, nightly ETL jobs that run past morning, reports that take 40 minutes to render.
The problem is rarely SQL Server itself. SQL Server 2022 is a mature, high-performance database engine with columnstore indexes, intelligent query processing, query store for regression detection, and native JSON support. The problem is what has accumulated around it over the years: stored procedures written by developers who left a decade ago, missing indexes that the missing index DMV has been begging for since 2018, parameter sniffing causing query plans that flip between 200ms and 200 seconds depending on which customer ID runs first, and tempdb contention from a single data file configuration that was never corrected after the initial install.
FreedomDev has been inside enterprise SQL Server environments for over two decades. We are not a generic cloud consultancy that treats SQL Server as one checkbox among many. We are the team that opens Activity Monitor at 2 AM when your overnight batch window blew past its deadline. We read execution plans the way a mechanic reads engine diagnostics — not just the estimated plan, but the actual plan with runtime statistics, looking for the implicit conversions, the key lookups, the hash spills to tempdb that explain why a query that should take 3 seconds takes 3 minutes.
This page covers the core areas of our SQL Server practice: performance tuning for slow databases, on-premise to cloud migration (Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VMs), SSIS/SSRS/SSAS development and migration, high availability with Always On Availability Groups, and the specific project types we handle. If you are a DBA overwhelmed by a growing environment, a CTO evaluating Azure migration, or a developer fighting query performance, this is the practical breakdown of what we do and what it costs.
Performance tuning is where most engagements start. A database that was fine two years ago is now slow — queries that ran in seconds now take minutes, batch jobs overrun their window, users complain about timeouts. We start with the wait statistics (sys.dm_os_wait_stats) to identify the bottleneck category: is it CPU-bound, IO-bound, memory pressure, blocking, or network? Then we dig into the specifics. Missing index DMVs (sys.dm_db_missing_index_details) reveal indexes SQL Server has been requesting. Query Store shows plan regressions — queries that suddenly got worse because the optimizer chose a different execution plan. We analyze the top resource-consuming queries, look at actual execution plans for implicit conversions (the varchar-to-nvarchar comparison that kills index seeks), key lookups that should be eliminated with covering indexes, and parameter sniffing problems where a cached plan optimized for one parameter value performs catastrophically for another. Fixes range from simple index creation and statistics updates to query rewrites, plan guides, OPTIMIZE FOR hints, and sometimes schema changes. Typical engagement: 2-4 weeks, $10K-$40K, with measurable before/after metrics on every query we touch.
Three target options, each with different tradeoffs. Azure SQL Database is fully managed PaaS — no patching, automatic backups, built-in high availability — but it does not support cross-database queries, SQL Agent jobs, CLR assemblies, or linked servers. Azure SQL Managed Instance is near-100% compatible with on-premise SQL Server, supports cross-database queries and SQL Agent, and is the right choice for lift-and-shift when your application uses features that Azure SQL Database does not support. SQL Server on Azure VMs gives you full control and full compatibility but you own the patching and backups. We run Azure Database Migration Service (DMS) assessments to identify compatibility issues before any migration starts, then execute the migration with minimal downtime using transactional replication or log shipping for cutover. Pricing reality: Azure SQL Database starts at roughly $5/month for basic tier but enterprise workloads typically run $500-$3,000/month for business-critical tier. Managed Instance starts around $350/month for 4 vCores. We help you right-size so you do not overpay on day one or hit performance walls on day thirty.
SQL Server Integration Services (SSIS) is still the ETL workhorse for Microsoft-centric enterprises. We build SSIS packages for data warehouse loading, cross-system data synchronization, file processing, and API-to-database ingestion. For organizations migrating to Azure, we handle SSIS-to-Azure Data Factory (ADF) migration — converting SSIS packages to ADF pipelines or running them in Azure-SSIS Integration Runtime when direct conversion is not practical. SQL Server Reporting Services (SSRS) is being sunset after SQL Server 2022 — we migrate SSRS reports to Power BI Report Server or Power BI Service, converting paginated RDL reports and reconfiguring subscriptions. SQL Server Analysis Services (SSAS) tabular and multidimensional models power enterprise BI — we build semantic models, optimize DAX calculations, and migrate on-premise SSAS to Azure Analysis Services when cloud is the target.
Always On Availability Groups (AGs) are the production HA standard for SQL Server 2016+. We architect and deploy Always On configurations — synchronous replicas for automatic failover within a datacenter, asynchronous replicas for disaster recovery across regions, read-only secondary replicas to offload reporting workloads from the primary. The architecture includes a Windows Server Failover Cluster (WSFC), proper quorum configuration (cloud witness for Azure hybrid, file share witness for on-premise), listener configuration for transparent client redirection, and connection string setup so your application fails over without code changes. Beyond Always On, we implement log shipping for simpler DR scenarios, transactional replication for distributing data to reporting servers, and backup strategies with point-in-time recovery testing — because a backup you have never restored is not a backup.
Database design and schema optimization for new applications. Stored procedure and T-SQL code review and refactoring. tempdb contention resolution (trace flags 1117/1118, multiple data files, memory-optimized tempdb metadata in SQL Server 2019+). Database consolidation — merging 15 SQL Server instances onto 3, right-sizing, licensing optimization. Version upgrades (SQL Server 2012/2014/2016 to 2022) with compatibility level testing. Security hardening — TDE implementation, row-level security, dynamic data masking, audit logging for compliance. Deadlock analysis and resolution using Extended Events. Capacity planning and growth forecasting based on historical resource consumption.
Query Store is the single most impactful feature added to SQL Server since 2016. It captures query plans and runtime statistics over time, making plan regression detection trivial — when a query suddenly gets slow, Query Store shows you exactly when the plan changed and lets you force the previous good plan while you investigate. We enable and configure Query Store on every SQL Server 2016+ database we touch: setting appropriate retention periods, configuring capture modes, establishing baselines, and training your team to use the built-in reports. SQL Server 2022 extends this with intelligent query processing — adaptive joins, memory grant feedback, interleaved execution for multi-statement table-valued functions, and parameter sensitivity plan optimization that generates multiple plans for parameter-sniffing-prone queries. These features work automatically when you set the right compatibility level, but understanding when they help and when they interfere requires the kind of execution plan analysis experience we bring.
Skip the recruiting headaches. Our experienced developers integrate with your team and deliver from day one.
Our ERP database had gotten so slow that order entry took 20 seconds and month-end reports ran all night. FreedomDev spent three weeks analyzing execution plans and wait stats, created missing indexes, fixed parameter sniffing in our core stored procedures, and reconfigured tempdb. Order entry dropped to under 2 seconds. Month-end reports finish in 45 minutes. We should have called them two years ago.
A West Michigan manufacturer running a custom ERP on SQL Server 2016. The system had grown from 50GB to 800GB over eight years. Order entry screens took 15-20 seconds to load. Month-end close reports ran for 6 hours. The nightly ETL to the data warehouse failed three nights a week due to timeout. Root causes: 43 missing indexes identified by the missing index DMV that had been accumulating suggestions for years, a critical order lookup stored procedure suffering from parameter sniffing (the plan cached for customer ID 1 with 12 orders was being reused for customer ID 5000 with 2.4 million orders), and tempdb configured with a single data file on a server with 16 CPUs causing allocation contention. We created the missing indexes with proper included columns, applied OPTIMIZE FOR UNKNOWN to the parameter-sniffing procedures, reconfigured tempdb with 16 data files, and updated statistics across all tables. Order entry dropped to under 2 seconds. Month-end reports completed in 45 minutes. ETL has not failed since.
A financial services company with three SQL Server 2014 instances (total 1.2TB) running in their own datacenter. Hardware was end-of-life, SQL Server 2014 extended support was expiring, and they wanted to eliminate datacenter costs. We ran Azure Database Migration Service assessments against all three instances, identified 14 compatibility issues (mostly deprecated syntax and cross-database queries), remediated the application code, and migrated to Azure SQL Managed Instance using online migration with log replay for near-zero downtime cutover. Post-migration: implemented geo-replication for DR, configured Azure Defender for SQL threat detection, and set up automated performance recommendations. Monthly infrastructure cost went from $8,500 (hardware amortization + datacenter fees + DBA time for patching) to $4,200 (Managed Instance Business Critical tier with reserved capacity pricing). More importantly, they eliminated the patching burden and gained automatic backups with 35-day point-in-time recovery.
An enterprise with 120+ SSIS packages running on a dedicated SQL Server Integration Services server. Packages handled everything from flat-file imports and FTP pulls to complex data warehouse loading with slowly changing dimensions. Moving to Azure meant the on-premise SSIS server had to go. We categorized the packages: 40 were simple source-to-destination loads that converted directly to ADF Copy Activities with minimal effort. 55 were complex transformations that we rebuilt as ADF Data Flows (the Spark-based transformation engine). 25 used custom Script Tasks with .NET code that had no direct ADF equivalent — for these we deployed Azure-SSIS Integration Runtime, which runs actual SSIS packages in the cloud without modification. The hybrid approach (native ADF + Azure-SSIS IR for the complex packages) was pragmatic: it eliminated the on-premise server while avoiding a 6-month rewrite of legacy .NET transformation logic.
A healthcare organization running patient records and billing on SQL Server 2019 with no high availability — a single server with nightly full backups to a network share. Any server failure meant up to 24 hours of data loss and 4-8 hours of recovery time. We deployed a two-node Always On Availability Group with synchronous commit for zero data loss automatic failover, plus an asynchronous replica in a secondary datacenter for disaster recovery. Configured a cloud witness in Azure for quorum, set up the AG listener so the application connection string did not need to change, and offloaded reporting workloads to the read-only secondary replica — which also resolved the locking contention that had been slowing down the billing application during report generation. RPO went from 24 hours to zero. RTO went from 4-8 hours to under 30 seconds for automatic failover.