SQL Server Standard 10.50.1600.1 (SQL Server 2008 R2 RTM) Mirroring

[Osamelgendy]

I have a very old version of SQL server hosted on Windows 7, and I need to know which option is applicable if I want to extract data from it using mirroring. Or am I stuck with batch extraction?

Option A	Create a modern secondary copy on SQL Server 2019/2022 and keep it synchronized from the SQL Server 2008 R2 source using log shipping or transactional replication, then use that secondary for Fabric ingestion or native mirroring.
Option B	Upgrade the existing machine OS (Windows 7 → Windows 10/11 or Server 2022) and SQL Server (2008 R2 → 2019 Standard). Full in-place upgrade.
Option C	Use a batch file extract approach: scheduled SQLCMD or BCP export from SQL 2008 R2 to flat files (CSV/JSON) on a network share, then ingest into Fabric Lakehouse via ADF. No SQL connectivity to Fabric required.

[v-prasare]

Hi @Osamelgendy,

if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[v-prasare]

Hi @Osamelgendy,

if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[v-prasare · Accepted solution]

Hi @Osamelgendy,

If upgrading the existing SQL Server 2008 R2 environment is not possible or carries some operational risk, then, Option A would be the better approach in your case.

You can absolutely use Transactional Replication or Log Shipping to keep a modern SQL Server instance (like SQL Server 2019/2022) synchronized with your SQL Server 2008 R2 source.

SQL Server supports replication across different versions within the same topology, as long as the Publisher version is less than or equal to the Distributor version. This means SQL Server 2008 R2 can act as the Publisher, and a newer SQL Server instance can act as the Subscriber. 

Between the two options:

• Transactional Replication is generally more practical if you need near real-time synchronization, since it propagates incremental changes as they occur while maintaining transactional consistency between systems.
• Log Shipping is also possible, but it works by continuously applying transaction log backups from the primary to a secondary database, where only the primary database is available for read/write activity at any given time. 

So Log Shipping is typically more suited for disaster recovery or migration scenarios, whereas Transactional Replication is better for reporting or downstream ingestion use cases like Fabric.

Also, maintaining two synchronized databases is not considered a bad practice. In fact, it is a common modernization pattern used when legacy production systems cannot be upgraded immediately. The secondary database can safely be used as an ingestion or reporting source without impacting the production workload.

So if upgrading is risky, you can:

• Keep SQL Server 2008 R2 as your production system
• Replicate the data to SQL Server 2019/2022
• Use the modern replica for Fabric Mirroring

This approach allows you to modernize your ingestion layer without making changes to the legacy production environment.

Thanks,

Prashanth

---

[NandanHegde]

The approach depends on what is the frequency of syncronization that you need on the Fabric side?

If it is near real time, then Mirroring is the best option.  And for that the best scope would be for you to use Option B rather than creating a replica.

[Osamelgendy]

if it's not possible, or has some risks (I don't know how to upgrade, if you can enlighten me), Option A would be better? is Transactional Replication or log shipping parctical with an issue like that?  or it's not good to have 2 databases all the time