Understand, however, that merely moving to SQL Server isn't a "magic bullet". To see true performance increases, you'll want to move as much processing as possible to the server (i.e. Views and Stored Procedures) and learn to use SQL to work with data. A lot of the performance issues seen with Access have to do with "bound" forms - that is, forms with a RecordSource, that contain Controls with ControlSources defined. When you do this, you allow Access to handle the data manipulation, and Access can be very slow with that.
Unbound applications mean YOU handle all data interaction, from filling the forms to updating data to deleting data etc etc. It also means, typically, that your forms will load faster (since you can often significantly limit the number of records being viewed) and thus your performance will improve. Moving your data methods to the server (by using Stored Procedures, perhaps) can significantly improve your performance, whether you use a bound or unbound application.
But again - there is no single thing you can do to make your application faster. in general:
Work with as little data as possible. If you're giving your users a list of Customers, do they really need to see ALL customers, or just those active within the last 30 days. This applies to Forms as well as Combos and Listboxes.
Limit the use of subforms, listboxes and combos. Each of those make a connection to the database (unless you use the .AddItem method for the combos/listboxs, that is) and can affect performance. Subforms especially can be a big performance hit.
With an unbound app, use SQL for data updates/inserts instead of Recordsets, where possible. Building a recordset, looping through a recordset etc etc takes time.
Build small, tight forms. Users LOVE to see everything on one form, but doing so is a huge performance hit. If you're working with Customer data, show Customer data, not Customer + Order + Billing + Contacts + History data. Have buttons to show those items if needed.
Same with Reports - build small, tight reports for anything you must print often. You'll likely need historical reports as well, and those will certainly be much more bloated than others, but in general, for day-to-day use your reports should be as streamlined as possible. And again, avoid the use of Subreports where possible.
Learn to build proper queries. Include ONLY those fields that are necessary for the task. Avoid calculated columns (i.e. where you add two columns together) and definitely avoid using IIF in a query. Don't reference objects in your query (i.e. set the Criteria to a Form like this: =Forms!SomeForm!SomeControl) - instead, open your query with the proper WHERE clause.
Learn the fine art of Indexing. A properly indexed table will perform much better than one where you accept the standard defaults Access provides (assuming you're dealing with a Jet database, that is).
Specifically in regard to Jet databases: Turn OFF SubDataSheets (a property of your Jet tables - these should all be set to [None]).
Turn OFF Name AutoCorrect
But most importantly (at least to me):
Start with a properly normalized database structure. Jet, SQL Server, Oracle etc etc are ALL designed around the concept of related data. They can handle non-related, poorly built databases, but they work much, much better when your data is properly normalized and stored correctly.
So start where any good project starts - at the ground level. Learn the basics of building tables and relating data. Learn how to figure out the major data entities being used by your app, and how those should be stored, and how those should be related. Learn how to properly use Joins for queries to bring those tables together.
