In SSL there are two areas where SHA-1 or SHA-256 may be used:
- in the specific entrails of the protocol itself, for the internal "PRF" (a function used during the handshake) and for protecting the integrity of subsequent data exchanges;
- as part of the signature over the server's certificate, and its CA certificate, and so on.
SSL 3.0, TLS 1.0 and TLS 1.1 use MD5 and SHA-1, not SHA-256. If you want to phase out SHA-1, then you need to switch to TLS 1.2. From this answer and its comments, you can see that support of TLS 1.2 by browsers is not a given, and is slow to percolate throughout the industry. IE on Windows XP will certainly not support TLS 1.2. In particular, many Android-based devices will use old versions of Android and its browser, and won't be updated soon. Fortunately, you can configure your server to advertise TLS 1.2 support but fall back to previous versions if the client does not support it; this is the normal behaviour of a SSL handshake, and should ensure a smooth transition.
What XP+SP3 supports about SHA-256 is the second point: certificates signed with SHA-256 as underlying hash function. This works. This page from digicert (a commercial CA) argues for SHA-256 support, and by that it means SHA-256 support in certificates; when it claims "browser support" it talks about the certificate validation, not TLS 1.2. According to that page, SHA-256 in certificates seems to work "everywhere". They don't tell anything about Android, but chances that Android is up to SHA-256 support because it has supported SHA-256 internally since day one (it is based on Java, which has known SHA-256 for years).
To sum up: you can use SHA-256 for the certificates; it will work (almost) everywhere. You cannot require TLS 1.2 yet (too many client browsers out there cannot handle it) but you can support it, and decide to prohibit previous versions (those which use SHA-1 internally) at a later date.