Its possible with a recovered database, to make it so that it will start accepting log restores again. Getting the LSN's accurate is a bit fiddly - but this solution is ideal if you're relocating a production database to a new server and you need the ability to fail back to the original, if things go wrong.
Assuming you are logshipping to the new server you should stop all connections to the source database, apply all the log (or diff) backups to the target server.
At this point you should back up the tail log, this is the the final log backup taken on the source database, and if you issue with the backup with 'norecovery' it effectively put that database into standby - you can then recover the warm standby (on the target).
Keep taking regular log backups on the new promoted server, and these can later be applied to the former live server.
This will seriously limit downtime if you need to failback.
backup log Poker to disk = 'y:\poker_tail_log.bak'
with norecovery