In order to take advantage of the changes in Drupal 7, Views has gone through several API changes.
Here's what you should know.

Handler registry

Views now uses Drupal's dynamic-loading code registry.
You can safely remove your implementations of hook_views_handlers(), since they are no longer used.
Please remember to specify the handlers in your module's .info file. For example:

Removed handlers

Note that views_handler_filter_float has been removed.
This functionality is now handled by views_handler_filter_numeric.
There's no need for having a special handler any more, thanks to the new DB layer in Drupal 7.
views_handler_sort_formula has been removed.
Everyone who used it can extend from views_handler_sort, too.

Ctools dependency

Views requires ctools now, so it can use the dependency system of ctools.
The only thing you have to do is to remove views_process_dependency.

placeholder() generates a automatic unique placeholder for you.
add_where with operator 'formula' can be converted to add_where_expression.
add_having with operator 'formula' can be converted to add_having_expression.

Changed place for display specific settings

In the new ui the new place for display settings is at the top of the second column.
Therefore use something like this code in your display plugin:

Changed filter settings and associated class variables

'optional' and 'single' are now 'required' and 'multiple', the logic is now opposite.
Also, the 'no_single' and 'no_optional' class variables (known as "object flags" in the API docs)
are now 'always_multiple' and 'always_required'.

Changed argument settings

See the init() function in views_handler_argument for an overview of everything
that changed.
1. The default actions 'summary asc', 'summary desc', 'summary asc by count', 'summary asc by count'
have been replaced by a single 'summary' action (which takes the sort order and type as options).
2. Wildcards are now called exceptions.

6. The validator settings have been moved from $form['argument_validate'] to ['validate_options']
This means that dependent code in validate plugins needs to change.
Example change for views_plugin_argument_validate_user:

These functions are meant to be used in the render() functions of field handlers,
for fetching data (usually by alias) from the $values object, and for sanitizing values.
The abstraction of fetching data from rendering data is important because
different query backends have different ways of storing data in $values, and the field alias
is a SQL specific thing. So instead of overriding the whole render() function and copying
all of the logic there (as well as having to constantly keep up with upstream Views changes),
the backend can just override get_values(), which is significantly less code.
Of course, different ways of fetching and displaying data might require different
ways of sanitizing it, hence the usage of the sanitize_value() function.
Examples of converting render() field handler implementations:

Changed views_get_page_view

In contrast to 6.x views_get_page_view now does stores the current view, not the current page display.

Removed views-view-row-node

Due to changes in comment.module there is no extra views-view-row-node template needed to display the comments. If you do some custom stuff there you should now be able to do everything in your node.tpl.php.

Entity type Key on Base tables

During the development of the drupal7 version of views the entity type associated with a table got added to $data['name']['table']['base']['entity type']. It should be moved to $data['name']['table']['entity type'].

Changed views_plugin_style::render_grouping()

The parameters as well as the structure of the methods return have changed.
The method now accepts a third optional parameter called "$group_rendered".
This parameter defines whether to use the rendered or the raw field value for grouping.
Intention for adding the parameter was that the grouping could have been acted
unexpected if the rendered field contained unique values e.g. by using drupal_html_id().