We need to move an on-premises SQL Server Web Edition database of about 30 GB to a new server. It supports a web app with moderate reads and writes. We can stop the background jobs during cutover.
Is log shipping the best fit, or would backup and restore with a final log backup be simpler? We would like downtime measured in minutes, or less if practical.
Log shipping is a good fit if you want the destination mostly caught up before the window. Restore a full backup on the new server without recovering the database, then keep applying transaction log backups. At cutover, stop application writes and jobs, take and copy the final log backup, restore it, and recover the destination database. Then point the application at the new server.
Test the whole sequence, including the connection switch and application checks. The final log copy and restore might be quick, but the actual outage depends on your write rate, storage, network, and how long it takes to verify the app. Make sure the recovery model and backup chain support the plan.
For a one-time move, manual backup and restore may be enough without setting up log shipping. Restore the full backup ahead of time with the database left ready for more restores, then apply subsequent log backups and a final log backup during cutover.
That avoids copying the whole database during the outage. Rehearse it and time the final steps rather than promising a particular downtime. If the window is generous, even a straightforward full backup and restore during downtime might be worth testing for a database this size.
Check the edition and version feature matrix before investing in replication. Web Edition cannot act as a transactional replication publisher, although it can be a subscriber. Even where replication is available, setting it up and removing it afterward can be a lot of work for a single migration.
The database is only part of the move. Inventory logins, permissions, SQL Agent jobs, linked servers, and other instance settings the application relies on. Script what you need and check that database users still map to the right logins on the destination. PowerShell tooling such as dbatools can help with some of that work.
Keep the jobs disabled on the new server until cutover is complete, and make sure they cannot run against both copies. Check licensing too, especially if the source and destination need to run at the same time during preparation.
Build a rehearsal that resembles production and measure it end to end. Include stopping traffic, the final restore, switching connections, and checking the app. A few seconds is a much tougher target than a few minutes, and a migration method alone does not provide ongoing high availability.
If brief interruptions are unacceptable for patching and other maintenance too, look at the availability design for the application and database separately from this move. That may mean different infrastructure or a different SQL Server edition.
Answers are reviewed before publication.
9am_status_update:
Also decide how you will prevent writes to the old database after the switch. A rollback gets more complicated once the new database has accepted writes.