If you're evaluating SSRS alternatives and want to keep your existing RDL report definitions, Bold Reports is the most feature-complete non-Microsoft rendering engine available. It reads RDL files natively, supports paginated output, and runs on Linux — which means you can deploy on AWS, Azure, or any Docker host without Windows Server licensing.
This walkthrough covers what I learned migrating nearly 200 production SSRS reports to Bold Reports for a multi-jurisdictional regulatory program. It's not a product review — it's a practitioner's guide to what actually works, what breaks, and what you need to configure before going live.
What Carries Over from SSRS
Bold Reports uses the same RDL (Report Definition Language) format that SSRS uses. This means the core report structure is preserved when you upload an RDL file:
- Report layouts. Headers, footers, page breaks, margins, and print sizing all render correctly. Tablix (table/matrix) components maintain their row and column groupings. If your report prints on legal paper with specific margins, it will still print on legal paper with the same margins.
- Parameters. Report parameters carry over including cascading parameters, default values, and multi-value parameters. The parameter panel in Bold Reports looks different from SSRS, but the functionality is equivalent.
- Expressions. Most VB.NET expressions in report fields work — IIF, Switch, Format, aggregation functions (Sum, Count, Avg), and scope references. Bold Reports has its own expression engine that handles the same syntax.
- Subreports. Subreport references are preserved. You need to publish the subreports first (or simultaneously), and the parent report will reference them by name.
- Drillthrough. Drillthrough actions between reports work once both the source and target reports are published. Parameter passing through drillthrough links is supported.
- Charts and gauges. Bar, line, pie, scatter, and area charts render with the same data. Gauge components are supported. The visual styling may differ slightly from SSRS — colors and fonts are faithful, but anti-aliasing and rendering resolution can vary.
What Doesn't Carry Over
Not everything survives the move. These are the gaps I encountered:
- Custom assemblies. If your SSRS reports reference external .NET DLLs for custom functions, those will not work on Bold Reports. This is the single biggest compatibility gap. The workaround is to inline the logic as VB.NET expressions or move it to the SQL query layer.
- Complex custom code blocks. Bold Reports supports simple custom code (shared functions in the report's Code section), but complex class instantiations, external library references, and advanced VB.NET patterns may not execute. In my experience, about 5-10% of reports had custom code that needed refactoring.
- Subscriptions and schedules. SSRS subscriptions (email delivery, file share drops) do not migrate automatically. Bold Reports has its own scheduling system, but you need to recreate each subscription manually or build automation around their API.
- Folder structure and permissions. Your SSRS folder hierarchy and role-based access don't transfer. Bold Reports has its own category system and user/group permissions that you configure from scratch.
- Data source connections. Embedded connection strings in your RDL files reference SQL Server by default. If you're also changing databases (e.g., to PostgreSQL), every data source needs reconfiguration. Even if you're staying on SQL Server, the connection strings often reference internal hostnames that differ in your new environment.
Data Source Configuration: The Critical Step
Data sources are where most migrations stall. SSRS reports have connection strings embedded in each RDL file. Bold Reports supports two approaches:
Option 1: Shared data sources (recommended)
Create a shared data source in Bold Reports that points to your database. Then configure each report to reference the shared data source instead of its embedded connection string. This way, when your database credentials or host changes, you update one shared data source instead of editing every report.
Option 2: Inline credentials
Keep connection strings embedded in each RDL file. This is faster for initial testing but creates a maintenance burden — every credential rotation requires updating every report file.
There's an important RDL namespace gotcha here. Shared data sources in Bold Reports require the 2010 RDL namespace, while inline credentials work with the 2016 namespace. If you use the wrong namespace, reports render blank with no error message. This is the kind of undocumented behavior that costs days of debugging if you don't know about it.
Deployment Options
Bold Reports can run in three configurations. The right choice depends on your infrastructure strategy and team capabilities.
EC2 / VM Instance
Deploy Bold Reports on a Linux EC2 instance (or equivalent VM). This gives you full control over the server configuration, direct filesystem access for RDL uploads, and the lowest latency for report rendering.
- Best for: production workloads with 50+ reports, organizations that want full infrastructure control
- Typical instance: t3.large or m5.large (4GB+ RAM recommended for rendering)
- Considerations: you manage OS patches, SSL certificates, and backups
Docker Container
Run Bold Reports in a Docker container using Syncfusion's official image. This simplifies deployment and makes the installation repeatable.
- Best for: development environments, testing, and teams already using container orchestration
- Considerations: persistent storage for the internal database and report files needs volume mapping
- Can be deployed on ECS, EKS, or any Docker-compatible platform
Bold Reports Cloud
Syncfusion hosts and manages the Bold Reports instance for you. Zero infrastructure to manage — you upload reports and configure data sources through the web UI.
- Best for: small teams, organizations without dedicated DevOps, or quick proof-of-concept
- Considerations: higher latency for API operations (2-3x slower than self-hosted for writes), report count limits on lower tiers
- Free tier available for evaluation
Step-by-Step Migration Process
Here's the sequence I follow for every Bold Reports migration, refined across nearly 200 reports:
- Step 1: Deploy Bold Reports. Stand up your Bold Reports instance (EC2, Docker, or Cloud). Complete the initial setup wizard — create the admin account and configure the internal metadata database.
- Step 2: Create shared data sources. Before uploading any reports, create shared data sources for each database your reports connect to. Test each connection to confirm it reaches your database.
- Step 3: Create the category structure. Bold Reports uses "categories" instead of SSRS folders. Create a category hierarchy that matches your SSRS folder structure (or take the opportunity to reorganize).
- Step 4: Upload RDL files. Upload reports via the Bold Reports API or web UI. If your reports use inline data sources, the embedded connection strings will be used as-is. If you're using shared data sources, configure the data source mapping during upload.
- Step 5: Validate rendering. Open each report in the Bold Reports viewer and verify it renders correctly. Check parameters, pagination, totals, and formatting. Compare output against the SSRS version for critical reports.
- Step 6: Configure access control. Create user accounts and groups. Assign permissions to categories and individual reports. Bold Reports supports report-level and category-level permissions.
- Step 7: Set up embedding (if needed). If you embed reports in a web application, configure the Bold Reports embed API. This requires generating an embed secret and registering users for authentication.
Common Pitfalls I Encountered
- Namespace mismatch. Bold Reports is sensitive to the RDL namespace version. Reports with 2016 namespace render correctly with inline data sources but render blank when using shared data sources (which require 2010 namespace). There is no error message — the report just shows empty.
- Connection string format. Bold Reports expects specific connection string patterns. For SQL Server, use
Initial Catalog=instead ofDatabase=. IncludeEncrypt=false;TrustServerCertificate=trueif your SQL Server does not have a trusted certificate. - Credential format in RDL. If embedding credentials in RDL files, use
<UserName>and<PassWord>XML elements (note the capitalization). Getting this wrong produces authentication failures that are hard to debug. - Duplicate reports from batch upload. If a batch upload fails partway through and you retry, you can end up with duplicate reports. Bold Reports does not automatically deduplicate by name. You need cleanup logic or idempotent upload scripts.
- Internal database defaults. Bold Reports ships with a default data source name that can conflict with your report data sources. Rename or remove the default data source before publishing reports.
When Bold Reports Is the Right Choice
Bold Reports is the strongest option when:
- You have 50+ paginated SSRS reports and rebuilding them in a dashboard tool is impractical
- Reports must maintain pixel-perfect fidelity for print output (regulatory forms, mailing labels, invoices)
- You want to run on Linux to eliminate Windows Server licensing
- You need to embed reports in a custom web application via iframe or JavaScript API
- You're migrating databases to PostgreSQL and need a rendering engine that supports non-Microsoft data sources
If your reports are simple charts and tables (not paginated), or if you're committed to the Microsoft ecosystem long-term, Power BI Report Server may be a better fit. See our paginated reports comparison for a detailed breakdown of all the options.
Steve Harlow is the founder of ReportBridge. He migrated nearly 200 SSRS paginated reports to Bold Reports on PostgreSQL for a multi-jurisdictional regulatory program. ReportBridge automates the upload, SQL conversion, and data source configuration steps described in this guide. Questions? steve@report-bridge.com