what is the best practice when making changes to the the application and database? I need to make changes to an application which utilizes a database that is replicated across locations. I was wondering what the best practice is when working with databases and making changes to the database. 

I will be backing up the database to dev environment and making changes to both the application and the database. Then when testing the application and the database I will likely make changes to the records. In that case, would it make sense run the t-sqls that I applied in the dev to the production database?
That's a big topic. The tactics depend in part on how big a change you're making. The strategy is that every move to production breaks nothing. Loosely speaking, that means 


you add "new things" to the database, 
alter all application code to use the new things instead of the old things, 
then, if prudent, remove the old things.


That equates to one to three moves to production. (I prefer three, with a prudent amount of time between them. Other developers might have more appetite for risk than I do.)

The most accessible online document might be Evolutionary/Agile Database Best Practices. It's relevant to some extent regardless of whether you follow agile practices. Look at Database refactoring and Agile data modeling first.


  would it make sense run the t-sqls that I applied in the dev to the production database?


That depends on what kinds of problems you uncovered, how you documented them, and whether the TSQL code is under version control. Writing TSQL is software development; all the principles of good software development apply.