maybe take a copy of the PROD table / data first - "just in case" ? 
SELECT *INTO dbo.TEMP_diagnosis_status_20140115FROM dbo.diagnosis_status
then you can use that to recover the PROD table's data exactly as it was if something goes wrong.Make sure people do not update diagnosis_status on PROD after you take this copy, until you have finished, and tested, your "import".You might be able to do this:BEGIN TRANSACTIONGOTRUNCATE TABLE dbo.diagnosis_statusGOINSERT INTO dbo.diagnosis_statusSELECT *FROM TestDB.dbo.diagnosis_statusGO-- If NO errors:COMMIT-- Or if there ARE errors:ROLLBACK
If Test DB is on another server, AND there is a linked server to use to connect to it then you can do this instead:FROM MyLinkedTestServer.TestDB.dbo.diagnosis_status
if there is NO linked server either create one!! or do as Visakh says and use Export/Import wizard.NOTE: If the DDL Structure of the table has changed in TEST then it is more complicated. You would need to rollout a "patch" to the structure of the PROD DB, and then copy the data across. It is also possible that all applications that use the database would need to be, simultaneously, updated to become "aware" of the structure change.Final point: the data in your diagnosis_status table has presumably ONLY changed on TEST DB and has NOT changed on PROD? Otherwise any changes to the data, made on PROD, will be lost when you copy over from TEST. If you need "some & some" then you will need to build a selective import from TEST. If that's the case ask and we can help with that.Don't forget to DROP TABLE dbo.TEMP_diagnosis_status_20140115
in a week or two's time if all goes well
(That's why I use the "TEMP_" prefix, and the Date suffix, so that when looking at the database in a month's time you/Admin can say "That can't be required anymore" and drop it. All such tables will be grouped alphabetically under "TEMP_", and the Date tells you WHEN it was created, and thus how Old/Stale it is now.)