Long term, no. The plugin is not actively maintained and depending on it past a major WordPress release is risky. Short term, SleekView lets you keep working with the data while you plan the migration carefully. The exit ramp is real: a modern view today, a clean export tomorrow, a planned migration when the new stack is ready.

Yes. Export from a SleekView with the columns you want, transform the CSV or JSON, and import into a new schema using a migration script or another plugin. The grid makes it easy to spot bad rows first, like users with missing required fields or duplicated employee IDs, so the migration starts from clean data rather than carrying problems forward.

No. SleekView writes to the same columns the plugin uses, so the original UI keeps working alongside the modern view. Custom code reading the Cimy tables also continues to function. The two interfaces are different reads and writes against the same underlying data, which means switching between them per task is fine.

Cimy stores some values as serialised PHP arrays for multi-select fields. SleekView previews the structure in the cell and lets you edit individual entries through a row drawer that respects the original shape. After editing, the value re-serialises in the same format the plugin wrote, so any code reading the value continues to work.

Yes. Each subsite has its own Cimy tables, since the plugin installs per site, and each subsite gets its own SleekView. A network admin can switch between subsites to manage each site's legacy data independently. There is no aggregated network view, which keeps the per-site data properly isolated.

It needs the Cimy tables to exist in the database. The plugin can stay deactivated if you only need read access through SleekView, which is sometimes the safer interim state if Cimy is causing PHP warnings on a current WordPress version. As long as the tables are intact, the view continues to work.

Yes. Apply your filters, decide on the columns the new schema needs, and export. The export becomes the source for the migration script that writes into wp_usermeta or your new stack's tables. Doing the export from SleekView rather than directly from phpMyAdmin gives you a chance to clean and shape the data first, which usually pays off.

SleekView reads tables, so it does not depend on a specific WordPress version's Cimy compatibility. As long as the cuef_data and cuef_fields tables exist with their schema intact, the view works on whatever WordPress version your site is running. This is part of why SleekView is a useful exit ramp from an unmaintained plugin like Cimy.