Migrating from Elastic EUI to MUI, Chakra, or Ant Design — The Complete Playbook

If you're reading this, your team probably built something on Elastic EUI and now you're stuck. Maybe you're not an Elastic shop anymore. Maybe the 188kb bundle is killing your Lighthouse scores. Maybe you're tired of fighting the Elastic License.

Whatever the reason, you need to migrate — and the docs won't help you. This is what I learned mapping 45 EUI components to their MUI, Chakra, and Ant Design equivalents.

Why teams leave EUI

Bundle size. EUI ships approximately 188KB gzipped. MUI's tree-shakeable architecture lets you import only what you use, typically resulting in 40-60% smaller bundles.

Elastic ecosystem lock-in. EUI was designed for Kibana. Its design language, component behavior, and even its color palette reflect Elastic's brand. Teams building non-Elastic apps find themselves fighting the library's opinions.

License concerns. EUI uses the Elastic License 2.0 (ELv2), which is not OSI-approved. Some legal teams flag this as a compliance risk for SaaS products.

Community. Stack Overflow questions, blog posts, and community plugins are significantly fewer compared to MUI (93k+ GitHub stars) or Ant Design (91k+).

The hardest parts nobody warns you about

EuiProvider is a monolith

EUI wraps theme, i18n, toast notifications, and global component defaults in a single provider. You can't extract components one-by-one without either keeping EuiProvider alive (bloating the bundle) or breaking everything at once.

What to do: Map every component that depends on EuiProvider context before writing a single line of migration code. You'll be surprised how many "independent" components break without it.

EuiBasicTable pagination is invisible

EUI manages pagination state internally. MUI's DataGrid requires you to manage paginationModel state yourself — page index, page size, total count. Teams that relied on EUI's "just pass items and it works" discover they need to add 20+ lines of state management.

// EUI — pagination is automatic

<EuiBasicTable items={data} columns={columns} pagination={pagination} />



// MUI — you manage the state

const [paginationModel, setPaginationModel] = useState({

  page: 0,

  pageSize: 20,

});

<DataGrid

  rows={data}

  columns={columns}

  paginationModel={paginationModel}

  onPaginationModelChange={setPaginationModel}

  pageSizeOptions={[20, 50, 100]}

/>

Color tokens are lossy

EUI uses semantic color names (subdued, accent, success) that map to its own palette. MUI uses Material Design colors (primary, secondary, error). There's no 1:1 mapping — subdued has no MUI equivalent. You'll end up building a custom theme layer just to bridge the gap.

The date math dependency

EUI depends on @elastic/datemath and moment. If your app uses EuiSuperDatePicker's relative date expressions ("now-15m"), you need to keep these dependencies or rewrite the date parsing logic. MUI doesn't have anything equivalent.

TypeScript migration patterns

This is where senior engineers spend most of their time.

Generic type mapping (Data Tables)

EUI uses generics to enforce type safety on row items:

// EUI

import type { EuiBasicTableColumn } from '@elastic/eui';



const columns: Array<EuiBasicTableColumn<User>> = [

  { field: 'name', name: 'Full Name', sortable: true },

  {

    field: 'status',

    name: 'Status',

    render: (status: User['status']) => (

      <EuiHealth color={status === 'active' ? 'success' : 'danger'}>

        {status}

      </EuiHealth>

    ),

  },

];

// MUI equivalent

import type { GridColDef } from '@mui/x-data-grid';



const columns: GridColDef<User>[] = [

  { field: 'name', headerName: 'Full Name', sortable: true },

  {

    field: 'status',

    headerName: 'Status',

    renderCell: ({ row }) => (

      <Chip

        color={row.status === 'active' ? 'success' : 'error'}

        label={row.status}

        size="small"

      />

    ),

  },

];

Key differences:

1. 
   EuiBasicTableColumn<T> → GridColDef<T> — different generic wrapper


2. 
   name → headerName — column display name


3. 
   render: (value) → renderCell: ({ row }) — receives params object, not raw value


4. MUI DataGrid requires @mui/x-data-grid as a separate package

Dealing with ExclusiveUnion

EUI uses a custom ExclusiveUnion utility to strictly prevent mixing button/anchor props:

// EUI — TypeScript Error! Can't have both onClick and href

<EuiButton href="/login" onClick={handleClick}>Login</EuiButton>

MUI handles this with the component prop:

// MUI — explicit about the underlying element

<Button component="a" href="/login">Login</Button>

<Button component={Link} href="/login">Login</Button> // Next.js Link

When migrating wrapper components, rewrite using MUI's typed component pattern:

// Before: EUI wrapper with ExclusiveUnion

type Props = EuiButtonProps; // includes ExclusiveUnion internally



// After: MUI wrapper with generic component type

type Props<C extends React.ElementType = 'button'> = ButtonProps<C>;

The 10 components with no direct equivalent

These will cost you the most time:

The migration strategy that works

After doing this across 45 components, here's the approach I'd use again:

Step 1: Audit. List every EUI component in your codebase. Count usage. Sort by frequency.

Step 2: Abstraction layer. Create wrapper components that currently re-export EUI:

// /components/ui/Button.tsx — Phase 1

export { EuiButton as Button } from '@elastic/eui';



// Phase 2 — swap the import, consumers don't change

export { Button } from '@mui/material';

Step 3: Leaf components first. Migrate buttons, badges, text, avatars — the components that don't depend on others. This builds confidence and momentum.

Step 4: Complex components last. Tables, modals, forms — these touch the most code and have the most API differences.

Step 5: Kill EuiProvider. Once all components are migrated, remove EuiProvider and @elastic/eui from your dependencies. Verify nothing breaks.

Interactive component reference

I built a searchable tool that maps all 45 EUI components to their MUI equivalents — including props, import changes, and which ones have no direct equivalent.

Try the interactive prop search table →

You can also paste EUI code directly into the converter and get MUI/Chakra/Ant Design output instantly:

Open the converter →

Or eject a production-ready component into your project:

npx @frontfamily/cli eject data-table -f react-mui

This guide is part of FrontFamily — a free tool for converting UI components between frameworks. 42 conversion paths, 219 verified component mappings, 18 ejectable patterns.