dbatools 2.8.4 extends `Invoke-DbaDbLogShipping` so a secondary can be added to an existing log-shipping configuration. That removes some manual work when teams add a reporting copy, migration target, or another recovery site. It does not make topology expansion risk-free: the new secondary must begin from a consistent state and integrate with jobs and monitoring that already protect production.
Why it matters in production
Planning starts with the purpose of the additional copy. Standby reporting, delayed recovery, migration staging, and disaster recovery require different restore delay, mode, frequency, retention, and access choices. Network throughput and backup-share capacity must support another consumer without delaying the existing secondary or leaving transaction-log files queued beyond the intended RPO.
Initialization should be rehearsed with real database size. Capture the base backup, transfer it securely, restore with the correct state, add copy and restore jobs, and confirm the monitor server recognizes the new relationship. Credentials, proxy accounts, share permissions, encryption keys, and SQL Agent ownership need explicit validation on every participating instance.
The first successful restore is only the beginning. Measure copy and restore latency, alert thresholds, cleanup behavior, network interruption, job retry, and the effect of primary maintenance. Perform a controlled recovery or role test so the secondary is proven usable. Automation should emit the evidence operators need rather than simply reporting that configuration commands completed.
Practical takeaway
The practical takeaway is to treat an added secondary as an expanded recovery contract. Use automation to reduce configuration error, but validate initialization, throughput, monitoring, security, and recovery behavior end to end. A second destination adds resilience only when it receives logs within target and the team can use it under pressure.