Moving Databases to New Datacenters
Your current situation :


90 GB database that you want to move to a new data center.
Database is in simple recovery.
You are thinking of using T-Rep to keep the data in sync.
There are many tables in the database that do not have Primary Key - this is a requirement for any tables to get published.
You already have a backup copied to the destination data-center.


I see many drawbacks in your approach :


T-Rep is not easy to setup as compared to other technologies. If there is any schema changes then it requires a new snapshot.
If you are going with T-REP then you have to make schema changes - add Primary Key to tables that dont have.
Doing any change to your existing database, your application has to be fully tested to avoid any unexpected behavior.
If your database is having large number of transactions and depending on network bandwidth between the 2 datacenters, there will be replication latency as well.


Based on my experience, below is my recommendation :


Change your database to full recovery. This is not a major impact as compared to creating PKs.
Ship the full backup of the source database - take backup with compression and enable instant file initialization. This will help you to cut down the restore time on destination data-center.
Restore database on the destination server WITH NORECOVERY.
Implement Logshipping and initialize it from the backup.
Have logshipping ship the logs every 1 min.
During the day of failover, take a last tail log backup on source and restore it on the destination using WITH RECOVERY. This will bring the destination database online.
Once the destination database is online, you have to sync up users.
You should change your web.config to point it to the new server.


You do not have to move any system databases. Make sure you do all the prep work before hand - script out logins, jobs, ssis packages, etc and create them on the destination server.

Refer to this answer for post restore steps and other best practices.

Note: You can implement Database mirroring (SYNC or ASYNC depending on the edition of sql server you are using) as well, but logshipping is just simple to implement and if you test it, it wont disappoint you. I have moved successfully terabyte database from one datacenter to another using the above technique and it works perfectly fine.


  The current production database will need to stay online and accessible throughout the entire migration process.


There will always be a downtime and you have to schedule it. Even if you invest paying high amount of money in solutions like clustering, when you failover, there will be some downtime. You have to balance out how much your company can invest in having a near to zero downtime vs what is available with some acceptable downtime.