Assuming your current table is something like
CREATE TABLE YourTable
Id INT IDENTITY PRIMARY KEY,
And that your existing code that references the table just performs basic DQL and DML commands against the table (i.e.
YourTable(Id) isn't referenced by a foreign key anywhere.
Then possibly the best way of getting up and running quickly (if you can't afford the downtime of rebuilding the whole table in one go) would be to rename that table (e.g. as
YourTableInt) and create a new table
CREATE TABLE YourTableBigInt
Id BIGINT IDENTITY(2147483648, 1) PRIMARY KEY,
You could then create a view with the same name as your original table name.
CREATE VIEW YourTable
You would need to write
INSTEAD OF triggers that route the Inserts/Updates/Deletes to the appropriate table. This could initially be based on whether Id was <= 2147483647 or not but that isn't going to work if you try and migrate rows in the background from the legacy table to the new one so probably best to do the following.
Apply deletes against both tables by joining on id
Apply updates to both tables by joining on id
Route all inserts into the new "YourTableBigInt" table. It shouldn't be possible for an insert through the view to enter an explicit identity that might clash with anything in the original table as any attempt to
set identity_insert YourTable will fail now that is actually a view.
You could then have a background process that deletes batches of rows from
outputs them into
YourTableBigInt. Once the original table is empty you can drop it and the view and rename YourTableBigInt to YourTable.