Moving SQL Server to different domain
What do you need to take into account when migrating SQL Server to another domain?
The steps below presume:

IP address will also change
SQL Server is NOT clustered

Steps:
A.  Backup:

BEFORE: backup the databases off-machine

B.  Services:

BEFORE: depending on the nature of the change/move, you may want to set service start to Manual for all SQL Service
AFTER: Once things or up and running properly, return service start to its original setting

C.  SA account:

BEFORE: If all administrator accounts are domain accounts or groups, temporarily enable the 'sa' account with a strong password
AFTER moving: once the domain-based accounts are setup in the new domain, 'sa' can be disabled again

D.  Service Windows account:

BEFORE moving: for each SQL-Server-related Windows service, change the service to use a LOCAL windows account or one of the built-in accounts
AFTER moving: grant the necessary privileges to the service new domain accounts.  When special permissions are not needed, the SQL Service Configuration Manager can be used to change the service account

E.  Windows domain accounts used to login to SQL Server

Re-create the needed accounts or use corresponding accounts in the new domain.
BEFORE moving, script out permissions for OLD domain accounts, including SQL permissions, Windows folder and file permissions, Windows permissions, etc.
AFTER moving, apply these scripts to the corresponding NEW domain accounts so they will have the same permissions

F.  IP Address: SQL Server (unless clustered) will use the new IP address

AFTER: Client applications that reference the service by IP address will need to be configured with the new IP address.

G.  Firewall:

AFTER: OLD firewall openings that are no longer used will need to be closed, NEW firewall openings may need to be created for SQL Server, OLAP services, SSRS between servers and clients

H.  DNS entries:

AFTER: verify DNS has correctly updated
AFTER: Clients and services that reference by DNS name, may need to be restarted AND/OR their host systems may need their DNS cache flushed.  For windows workstations, this can be done with &quot;ipconfig /flushdns&quot;

I.  Service Principle Names (SPNs).  Some standalone (and all clustered) instances use SPNs.

AFTER: The OLD SPN must be dropped and a NEW SPN must be created.  Although it's not recommended to use a SQL Server service account to manage (its own) SPNs, if this is the case, the NEW domain service account will need to be granted WriteServicePrincipalName&quot; privilege

J.  Client Network Utility Alias.

AFTER: Update any clients that use these will need to updated

K.  Client application and service connection configuration:

AFTER: Data Source Names (DSNs), connection strings, config files, Oracle TNS names for connections - will need to be udpated and applications and services may need to be restarted

L.  Internal machine name.

AFTER: If the machine name is also changing, SQL Server's internal machine name entry may need to be udpated
sp_dropserver 'MyOldMachineName'
go
sp_addserver 'MyNewMachineName','local'
go


M.  Merge Replication - If merge replication is in use, it will also need to be reconfigured.

BEFORE: ensure all replicas are up-to-date
AFTER: re-configure merge replation

Attributions - some information added from these sources:
https://serverfault.com/questions/49681/change-ad-domain-membership-of-a-server-2008-running-ms-sql-08
http://social.msdn.microsoft.com/Forums/en-US/sqlsecurity/thread/f3e8ff83-8fcd-4335-87fe-ea5641ae6b88