Salesforce behavior during an upgrade

As a Salesforce upgrade is only planned during the week-end, when the application has the minimum of connected users to decrease the operational impact, you probably never experienced such an upgrade in real time. Don't forget to check on a regular basis trust.salesforce.com to identify planned upgrades. What is the impact on both users and interfaces ?

Impact on the connected user

When starting the upgrade, Salesforce.com disconnects all users by invalidating their Session Id. This means that if a user tries to access a page, he will be redirected to the login page. He won't be able to connect until the upgrade process has finished. It's probably 5 minutes service disruption. The concern is when a user was updating data, he changed some fields and tries to save the record. As the session id is invalid, the new data will not be recorded, the user will have to do this operation again once the Org is live.

Impact on Interfaces

Sames effect, same consequence: when a sessionId is inactivated, and if an interface was running, the API gives you the following error:

{faultcode:'sf:INVALID_SESSION_ID', faultstring:'INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session', detail:{UnexpectedErrorFault:{exceptionCode:'INVALID_SESSION_ID', exceptionMessage:'Invalid Session ID found in SessionHeader: Illegal Session', }, }, }

You will be able to run your batch after the upgrade period.
As the upgrade window can break your batch, you will have both valid data and invalid data in your org if you tried to update some values (for an extract, you will get only a partial extract). To manage this, you will need to:

Plan your batches outside Salesforce upgrade windows
Implement a retry process that will allow you to run the same batch once again to continue the process without altering data already processed
To keep data consistency for a batch update, use transactions. It's native for batch Apex, but when using the API (dataloader, custom development, ETL connector...) you are not able to keep data integrity (you cannot emulate transactions). The only way is by creating Apex Webservices that will be accessed by your batch.
Monitor the execution and result. If your batch failed, you have to run it again after the upgrade process. This has an impact on your scheduling (stop cascade batchs and implement a retry every 30 minutes for example)

Collateral Impact of the new version

Users won't see any difference when using the new Salesforce release. User Interface enhancements, ergonomy changes or new modules aren't by activated by default. The administrator can activate new functionalities through the setup menu when he wants.
Interfaces will be able to access the new API and get the benefits of the changes. As long as you don't change your batches, you keep using the same API version number. You will have to change the endpoint used by your batches (or API version number of your apex or VisualForce code) to use the new API. The behavior will remain the same as long as you keep using the same version, even if Salesforce has upgraded multiple times since you created your batch.
Salesforce is keeping live old API versions together with the new API version, since years.

New API version

A new version of the Soap API will give you access to new objects. For instance, Domain, DomainSite, EventRelation and HashtagDefinition are 4 new standard objects that didn't exist in API 25.0 and where available starting API 26.0.
A new API version can deprecate standard objects too. For instance, EventAttendee and SiteDomain where deprecated in 26.0. (NewsFeed and UserProfileFeed in API 27.0).
This means that for your batches, you must not just change the endpoint, you need a full analysis to identify impacts by matching the changes with your API usage (objects, fields, methods, implicit behavior...)