First, always remember "large" is in the eye of the beholder. I've regularly worked with databases that were 100 - 400 GB. so yours don't seem that big to me.
That said: The primary purpose of (most) databases is to serve the needs of a user base, usually via an application of some sort. If application performance is good, then there's absolutely nothing wrong with database as large or far larger than yours.
I'd generally think of the hierarchy of what's most important as:
- Data recoverable with acceptable loss, in acceptable time, in case of emergency/disaster (note that the business owner should define acceptable here - download BrentOzar.com's First Responder Kit for (among a lot of other great stuff) a checklist for working out what timeframes are acceptable for the above. Of course, what most people want vs. what they're willing to pay for are often two different things....
- Separate environment for testing changes/updates to DB or to application
- Acceptable (or better) performance for most (or all) users;
- Ease of administration.
Note that the business owners want to put the third item on that list at the top. Until, of course, something happens because one of the first two items was skipped. If the higher-ups insist on changing the order, that's OK - but make sure it's documented, and that you've tried to make them understand the potential problems involved. Losing a day's worth (or more!) of orders due to a server issue, or trying to operate with an "updated" application that's significantly broken in some way (for example, can't take orders, or can't print them out to be shipped) is the only way some people learn. And, unfortunately, some people will blame the DBA, even when you've told them this could happen, and they chose to ignore it.
It's good to look ahead, and considering moving older data from your database to an archive of some sort is reasonable, even if it doesn't need to be done right away. However, that's the sort of thing that needs to be worked through with representatives of the user community, and with the business owner (usually not the same, note). Older data may still be needed on a regular basis; if it's not in the database the application sees, then it's not available. If you set up a separate interface to get to older data, it's still not convenient (and, there's a chance that someone will get mixed up, and manage to enter new data into the archived database). It may be more reasonable to look at partitioning your tables based on dates. The older data could be moved to a separate file that's still part of the same database.
As far as compressing the data, you mentioned in a comment that you'd tried compressing the database into a RAR archive. SQL Server data (and log) files are active as long as the server is up and running; if you tried to compress the actual .mdf and .ldf files, you'd wind up with a resulting file that wouldn't be valid. You should try to back up the databases. The built-in BACKUP DATABASE command in SQL Server allows you to compress the backups - mine usually wind up being about 1/6 th the size of the actual data (but your results may vary). You can right-click on the DB in SQL Server Management Studio, chose "Tasks", then choose "Backup...". I would still recommend doing this during a period when the database is least heavily used, and it may still be an issue, but it's at least worth a try.
If the backup files are still too large to easily move from the old server to the new one, or if the down time involved in doing so would be prohibitive, then consider a more gradual method of getting the database transferred to the new server. sog shipping (as noted in Rafael Piccinelli's answer) is definitely an option, especially if it may take several days to get everything moved and set up in the new environment. If the problem of moving the files is less severe, you could probably shortcut from actual log shipping to something simpler: Take a full backup of the database anywhere from a few hours to a day before go-live; then, take a differential backup right after the start of your down time. You can have the full backup restored (but not recovered) on the new server, waiting for the differential. That file would presumably be much smaller than your full backup, so copying it to the new server should be much faster. Once it's there, restore it to the new server, recover the database, and you should be ready to go.
Note: Whatever method you decide to use to move to the new server, do at least one successful test run before finalizing your go-live date.
